On Fri, 2009-01-16 at 18:43 -0500, Tom Lane wrote:
What is happening is that autovacuum_do_vac_analyze contains
old_cxt = MemoryContextSwitchTo(AutovacMemCxt);
...
vacuum(vacstmt, relids);
...
MemoryContextSwitchTo(old_cxt);
and at the time it
Attached are patches to fix the following compiler warnings that I see when
using gcc 4.3.2.
MASTER warning:
tablecmds.c: In function 'DropErrorMsgWrongType':
tablecmds.c:601: warning: format not a string literal and no format
arguments
REL8_3_STABLE warnings:
utility.c: In function
On Fri, Jan 16, 2009 at 10:23 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Looking at it some more, I notice that the SortGroupClause dependencies
are on the individual operators, which probably isn't good enough: the
operator *classes* have to exist or the parser will complain when trying
to make
On Sun, Jan 18, 2009 at 1:41 AM, Brendan Jurd dire...@gmail.com wrote:
... but I'm confused as to why 8.4
doesn't freak out when told to create a view it doesn't actually know
how to execute. Have the rules for evaluating views changed?
Update. Turns out that 8.4 DOES know how to execute
Brendan Jurd dire...@gmail.com writes:
Update. Turns out that 8.4 DOES know how to execute the view. If you
try to group on a user-defined composite type, 8.4 just goes ahead and
groups it, rather than giving the old could not identify an ordering
operator error.
Is there a hash opclass for
On Sun, Jan 18, 2009 at 2:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Brendan Jurd dire...@gmail.com writes:
Update. Turns out that 8.4 DOES know how to execute the view. If you
try to group on a user-defined composite type, 8.4 just goes ahead and
groups it, rather than giving the old could
Brendan Jurd dire...@gmail.com writes:
On Sun, Jan 18, 2009 at 2:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Is there a hash opclass for the type? 8.4 can group types that have
hash but not btree opclasses, but prior versions insisted on btree.
Well I sure didn't create one. I've only been
On Fri, Jan 16, 2009 at 10:23 AM, Tom Lane t...@sss.pgh.pa.us wrote:
However --- it's also the case that
pg_dump should dump all operators *and* operator classes before it gets
to views. So either you were doing something funny with the dump/reload
or else there's a circular dependency in
Simon Riggs si...@2ndquadrant.com writes:
Can we add something to memory contexts to make this fail every time?
No, not really. AFAICS the reason for Alvaro not seeing it must be that
on his machine the new transaction happens to allocate its
TopTransactionContext control block right in the
On Sat, 2009-01-17 at 11:35 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
Can we add something to memory contexts to make this fail every time?
No, not really. AFAICS the reason for Alvaro not seeing it must be that
on his machine the new transaction happens to allocate
Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
Can we add something to memory contexts to make this fail every time?
No, not really. AFAICS the reason for Alvaro not seeing it must be that
on his machine the new transaction happens to allocate its
TopTransactionContext control
Tom Lane t...@sss.pgh.pa.us writes:
Simon Riggs si...@2ndquadrant.com writes:
Can we add something to memory contexts to make this fail every time?
No, not really. AFAICS the reason for Alvaro not seeing it must be that
on his machine the new transaction happens to allocate its
Brendan Jurd dire...@gmail.com writes:
On Fri, Jan 16, 2009 at 10:23 AM, Tom Lane t...@sss.pgh.pa.us wrote:
However --- it's also the case that
pg_dump should dump all operators *and* operator classes before it gets
to views. So either you were doing something funny with the dump/reload
or
Simon Riggs si...@2ndquadrant.com writes:
Can we put a identifier into header of each control block, an ascending
value that is unlikely duplicate between calls? That way we'd be able to
tell immediately it wasn't the same block,
Same block than what? Unless you can somehow hide that ID
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
No, not really. AFAICS the reason for Alvaro not seeing it must be that
on his machine the new transaction happens to allocate its
TopTransactionContext control block right in the same place where the
old one was.
But freed
On Sun, Jan 18, 2009 at 5:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Interesting --- it works as expected in 8.2. The problem seems to have
been created by the introduction of arrays over composites in 8.3.
Congratulations on identifying the source!
Does this also explain the extra-weird
On Thursday 15 January 2009 02:08:42 Bruce Momjian wrote:
Added to TODO:
Have statement-level triggers fire for all tables in an
inheritance hierarchy
I don't think that was really the conclusion from the thread.
As far as I can interpret the opinions, statement level triggers
On Saturday 17 January 2009 11:44:07 Alan Li wrote:
Attached are patches to fix the following compiler warnings that I see when
using gcc 4.3.2.
MASTER warning:
tablecmds.c: In function 'DropErrorMsgWrongType':
tablecmds.c:601: warning: format not a string literal and no format
arguments
Peter Eisentraut pete...@gmx.net writes:
You apparently have your compiler configured with -Wformat-security. Our
code
doesn't do that. I think the cases the warning complains about are fine and
the way the warning is designed is a bit bogus.
Hm, only a bit. You know, we've had
Any objections adding the below to postgres.h?
#define VARLEN(PTR) (VARSIZE(PTR) - VARHDRSZ)
It adds a little more abstraction and cleans up userland code.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Brendan Jurd dire...@gmail.com writes:
Does this also explain the extra-weird output from HEAD, with the =
and = operators sorting earlier than the view, but the rest of the
operators sorting after it?
No, that comes from the fact that we have dependencies on those two
operators (but not the
Andrew Chernow a...@esilo.com writes:
Any objections adding the below to postgres.h?
#define VARLEN(PTR) (VARSIZE(PTR) - VARHDRSZ)
For the most part, you should probably be using VARSIZE_ANY_EXHDR
anyplace that that might be a good idea.
regards, tom lane
--
Sent via
Peter Eisentraut pete...@gmx.net writes:
On Thursday 15 January 2009 02:08:42 Bruce Momjian wrote:
Added to TODO:
Have statement-level triggers fire for all tables in an
inheritance hierarchy
I don't think that was really the conclusion from the thread.
As far as I can interpret the
Gregory Stark st...@enterprisedb.com writes:
There's an argument to be made that the code is easier to audit if you put the
%s format string in explicitly too.
Yeah, the risk this is trying to guard against is variables containing
% unexpectedly. Even if that's not possible, it requires some
24 matches
Mail list logo
