Hello
This code run without error, but do nothing
drop role x;
create role x;
create or replace function foo() returns void as $$
begin
grant root to x;
end;
$$ language plpgsql;
\dg x
revoke root from x;
postgres=# postgres=# DROP ROLE
postgres=# CREATE ROLE
postgres=# postgres$# postgres$#
Hello
I am stupid. 1) I don't call function.
I am sorry
Regards
Pavel Stehule
_
Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/
---(end of broadcast)---
TIP
There's a definitional issue here, which is what does it mean to be
counting index tuples. I think GIN could bypass the VACUUM error check
by always returning the heap tuple count as its index tuple count. This
One problem: ambulkdelete hasn't any access to heap or heap's statistics
Teodor Sigaev [EMAIL PROTECTED] writes:
One problem: ambulkdelete hasn't any access to heap or heap's statistics
(num_tuples in scan_index() and vacuum_index() in vacuum.c). So, ambulkdelete
can't set stats-num_index_tuples equal to num_tuples.
We could probably fix that by adding it to the
On Fri, Apr 28, 2006 at 10:14:09AM -0400, Tom Lane wrote:
Here I think it would be best to add an indclusterable column to pg_am.
Actually, does clustering on *any* current index type except btree make
sense? None of them have semantically interesting index ordering
AFAIR, so maybe we should
We could probably fix that by adding it to the stats structs that are
passed around during VACUUM. I'd rather not hardwire a GIN special case
in vacuum.c as per your quick hack.
ok. amskipcheck?
Here I think it would be best to add an indclusterable column to pg_am.
GIN is _always_
Teodor Sigaev [EMAIL PROTECTED] writes:
We could probably fix that by adding it to the stats structs that are
passed around during VACUUM. I'd rather not hardwire a GIN special case
in vacuum.c as per your quick hack.
ok. amskipcheck?
Oh, I was thinking of having VACUUM put the heap tuple
ok. amskipcheck?
Oh, I was thinking of having VACUUM put the heap tuple count into the
struct and then amvacuumcleanup could copy it over to the index tuple
count. A skipcheck flag only solves the cosmetic problem of not
getting the warning, it doesn't fix things so that the correct count
Teodor Sigaev [EMAIL PROTECTED] writes:
Huh? Why two? Either you are allowed to cluster on indexes of this
type, or you're not. I don't see the point of any other distinction.
amclusterable - as you suggest: Does cluster command something or not?
This is what we need.
amclustered -
Larry Rosenman wrote:
Simon Riggs wrote:
On Thu, 2006-04-27 at 14:53 -0400, Tom Lane wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
I'd like to see a more concrete definition of what we
want Autovacuum to output and at what levels.
autovacuum_verbosity
Should we call it
Takes clustering into account means nothing. We don't need that. Any
such consideration would be handled by the AM-specific amcostestimate
function.
Ok, I see. Sorry for misunderstanding. I thought that planner use that.
--
Teodor Sigaev E-mail: [EMAIL
Kris Jurka wrote:
Bruce Momjian wrote:
Log Message:
---
Modify Solaris compiler build rules to use the cpp preprocessor, the the
x86 file.
Well it compiles now, but it doesn't seem to work:
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=kududt=2006-04-28%2016:30:01
On 4/27/06, Tom Lane [EMAIL PROTECTED] wrote:
Brandon Black [EMAIL PROTECTED] writes:
I was wondering (for planning purposes) if anyone knew the status of
constraint exclusions moving up to query runtime and working for
joins.
The latter, done; the former, not on the radar screen IMHO.
I
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
So for you it would certainly help a lot to be able to vacuum the first
X pages of the big table, stop, release locks, create new transaction,
continue with the next X pages, lather, rinse, repeat.
This is perfectly doable, it
On Friday 28 April 2006 12:09, Larry Rosenman wrote:
Larry Rosenman wrote:
Simon Riggs wrote:
On Thu, 2006-04-27 at 14:53 -0400, Tom Lane wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
I'd like to see a more concrete definition of what we
want Autovacuum to output and at what levels.
Robert Treat wrote:
On Friday 28 April 2006 12:09, Larry Rosenman wrote:
Larry Rosenman wrote:
Simon Riggs wrote:
On Thu, 2006-04-27 at 14:53 -0400, Tom Lane wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
I'd like to see a more concrete definition of what we
want Autovacuum to output and
On Fri, Apr 28, 2006 at 04:08:41PM -0400, Robert Treat wrote:
The first is to add a column(s) to pg_class to hold last vaccum/analyze time
for each table. The upsides would be that this puts the information in a
readily accessable place that can be viewed from third party tools and
queried
Robert Treat [EMAIL PROTECTED] writes:
The first is to add a column(s) to pg_class to hold last vaccum/analyze time
for each table.
I really don't want us to do that. relpages/reltuples are already an
ugly wart. The fundamental problem with this (or indeed any of the
various proposals for
Martijn van Oosterhout kleptog@svana.org writes:
You know, rather than adding new columns to pg_class, why not extend
the stats collector to collect this information.
+1
regards, tom lane
---(end of broadcast)---
TIP 4:
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
You know, rather than adding new columns to pg_class, why not extend
the stats collector to collect this information.
+1
regards, tom lane
That sounds doable. And a lot less scary for me (as a
On Fri, Apr 28, 2006 at 03:18:56PM -0500, Larry Rosenman wrote:
Martijn van Oosterhout kleptog@svana.org writes:
You know, rather than adding new columns to pg_class, why not extend
the stats collector to collect this information.
That sounds doable. And a lot less scary for me (as a
On Fri, 28 Apr 2006, Theo Schlossnagle wrote:
What platform is that? (OS rev, architecture and word size)? I tested the
changes I submitted on Solaris 10 amd64.
$ uname -a
SunOS albert 5.9 Generic_112234-03 i86pc i386 i86pc
$ cc -V
cc: Sun WorkShop 6 update 2 C 5.3 Patch 111680-09
Martijn van Oosterhout wrote:
On Fri, Apr 28, 2006 at 03:18:56PM -0500, Larry Rosenman wrote:
Martijn van Oosterhout kleptog@svana.org writes:
You know, rather than adding new columns to pg_class, why not
extend the stats collector to collect this information.
That sounds doable. And a lot
Martijn van Oosterhout wrote:
On Fri, Apr 28, 2006 at 03:18:56PM -0500, Larry Rosenman wrote:
Martijn van Oosterhout kleptog@svana.org writes:
You know, rather than adding new columns to pg_class, why not extend
the stats collector to collect this information.
That sounds doable.
On Fri, 28 Apr 2006, Theo Schlossnagle wrote:
The file that uses the spinlocks:
/src/backend/storage/lmgr/s_lock.c
can be compiled standalone with -DS_LOCK_TEST
To get the test to compile I had to link in tas.o as the attached patch
shows. Unfortunately this doesn't work for platforms
On Fri, 28 Apr 2006, Theo Schlossnagle wrote:
Kris Jurka wrote:
Anyway the test exits with
Stuck spinlock (80618e9) detected at ./s_lock.c:355.
on a linux gcc build this exits with
Stuck spinlock (0x5013ad) detected at ./s_lock.c:402.
This seems like a different problem, no? The patch I
I was looking at what it'd take to handle attaching an error cursor
to the message about column foo must appear in the GROUP BY clause or
be used in an aggregate function, as per recent discussion here:
http://archives.postgresql.org/pgsql-sql/2006-04/msg00206.php
While we've now got the parser
I am thinking, what do we want to show by default about autovacuum in
the server logs. What if we output a line the first time autovacuum
runs successfully on server start?
---
Bruce Momjian wrote:
Robert Treat wrote:
On Friday 28 April 2006 19:06, Bruce Momjian wrote:
I am thinking, what do we want to show by default about autovacuum in
the server logs. What if we output a line the first time autovacuum
runs successfully on server start?
If Larry can do the work of getting details added into the stats
Robert Treat [EMAIL PROTECTED] writes:
If Larry can do the work of getting details added into the stats views, I'm
comfortable just setting all of the logging to debug1 and leaving it at that.
I still could see the idea of having a guc for an autovacuum specific log
control; I could see an
Hi,
there is a chance to add a STEP clause to the FOR statement in plpgsql?
something like
FOR i IN 1..100 STEP 2 LOOP
END LOOP
the STEP value must be a positive value because of the effect of the
REVERSE clause...
i think it's just a matter of fixing gram.y, plpgsql.h (to add
another
Jaime Casanova [EMAIL PROTECTED] writes:
there is a chance to add a STEP clause to the FOR statement in plpgsql?
This is not free: it'd require making STEP a reserved word (at least
within plpgsql) which is contrary to spec. I think you need to make
a pretty good case why the value of the
32 matches
Mail list logo
