Re: [HACKERS] Back branch update releases this week; beta postponed

--On 10. April 2011 13:53:52 -0400 Tom Lane wrote: In view of the recently-discovered data loss bug in pg_upgrade, it seems imperative to push out update releases fixing that as soon as possible. The core team has therefore decided to wrap back-branch update releases this Thursday for releas

Re: [HACKERS] Windows build issues

On Mon, Apr 11, 2011 at 22:16, Peter Eisentraut wrote: > On tor, 2011-04-07 at 16:20 -0400, Robert Haas wrote: >> It sure would be nice if someone would write a doc patch, or at least >> a wiki page, explaining all the permutations here...  I get the >> impression it's not that hard to set up if y

Re: [HACKERS] Windows build issues

On 04/12/2011 08:23 AM, Magnus Hagander wrote: On Mon, Apr 11, 2011 at 22:16, Peter Eisentraut wrote: On tor, 2011-04-07 at 16:20 -0400, Robert Haas wrote: It sure would be nice if someone would write a doc patch, or at least a wiki page, explaining all the permutations here... I get the im

Re: [HACKERS] Windows build issues

On Tue, Apr 12, 2011 at 14:51, Andrew Dunstan wrote: > > > On 04/12/2011 08:23 AM, Magnus Hagander wrote: >> >> On Mon, Apr 11, 2011 at 22:16, Peter Eisentraut  wrote: >>> >>> On tor, 2011-04-07 at 16:20 -0400, Robert Haas wrote: It sure would be nice if someone would write a doc patch,

Re: [HACKERS] Back branch update releases this week; beta postponed

Bernd Helmle writes: > --On 10. April 2011 13:53:52 -0400 Tom Lane wrote: >> The core team has therefore decided to wrap back-branch >> update releases this Thursday for release Monday 4/18. > Hmm, I would like to see the patch for >

Re: [HACKERS] WAL, xl_heap_insert and tuple oid mystry

Hi, >> Where is the OID of tuple stored in a WAL record of a >> tuple? If not with xl_heap_header, where is it stored? Is it >> stored at all? > It's stored in the "tuple data" portion. Is the OID also recorded with xl_heap_delete record as well or just the xl_heaptid? From my reading o

Re: [HACKERS] WAL, xl_heap_insert and tuple oid mystry

On 12.04.2011 19:42, jagan wrote: Where is the OID of tuple stored in a WAL record of a tuple? If not with xl_heap_header, where is it stored? Is it stored at all? > It's stored in the "tuple data" portion. Is the OID also recorded with xl_heap_delete record as well or just the xl

Re: [HACKERS] fn_collation in FmgrInfo considered harmful

I wrote: > So, unless there's a really good reason why fn_collation should be in > FmgrInfo and not FunctionCallInfo, I'm going to see about moving it. It looks like the single largest PITA involved in this change is that the FunctionCallN/OidFunctionCallN/DirectFunctionCallN families of functions

Re: [HACKERS] fn_collation in FmgrInfo considered harmful

On Tuesday, April 12, 2011 08:09:53 PM Tom Lane wrote: > 1. The existing names with a "C" appended (eg, OidFunctionCall2C) will > take a collation argument (in particular, this replaces the existing > DirectFunctionCall1WithCollation and DirectFunctionCall2WithCollation, > which seem a bit verbosel

Re: [HACKERS] fn_collation in FmgrInfo considered harmful

Andres Freund writes: > On Tuesday, April 12, 2011 08:09:53 PM Tom Lane wrote: >> 1. The existing names with a "C" appended (eg, OidFunctionCall2C) will >> take a collation argument (in particular, this replaces the existing >> DirectFunctionCall1WithCollation and DirectFunctionCall2WithCollation,

Re: [HACKERS] fn_collation in FmgrInfo considered harmful

On Tuesday, April 12, 2011 09:00:40 PM Tom Lane wrote: > Andres Freund writes: > > On Tuesday, April 12, 2011 08:09:53 PM Tom Lane wrote: > >> 1. The existing names with a "C" appended (eg, OidFunctionCall2C) will > >> take a collation argument (in particular, this replaces the existing > >> Direc

Re: [HACKERS] fn_collation in FmgrInfo considered harmful

Andres Freund writes: > On Tuesday, April 12, 2011 09:00:40 PM Tom Lane wrote: >> Hm, well, you got a better idea? I definitely want it *short*, because >> these are going to be in a lot of places. > Not really. Maybe DirectFunctionCall1Coll or even DirectFCall1Coll... xxxFunctionCallNColl wou

Re: [HACKERS] Windows build issues

On Tue, 12 Apr 2011 08:51:57 -0400, Andrew Dunstan wrote: that's in the SDK? If not, I still think that should be our primary option - I certainly don't see how it's obsolete. (and you can, afaics, still get the platform sdk with the correct version of the compiler (non-vs2010), but I haven't te

Re: [HACKERS] WAL, xl_heap_insert and tuple oid mystry

On Tue, Apr 12, 2011 at 7:55 AM, Heikki Linnakangas wrote: > Maybe the WAL record you're looking at is a full-page image? A record with a > full-page image includes a verbatim copy of the page, and the individual > tuple is omitted in that case. > It is? I thought full page images were only in ad

[HACKERS] [PATCH] Fix that NOSUPERUSER implies REPLICATION unless specified contrarily

Also add some regression tests for that behaviour. Found after seing a report about it in IRC by Daniel Grace. --- src/backend/commands/user.c |3 +- src/test/regress/expected/privileges.out | 35 src/test/regress/sql/privileges.sql | 37

Re: [HACKERS] WAL, xl_heap_insert and tuple oid mystry

Greg Stark writes: > On Tue, Apr 12, 2011 at 7:55 AM, Heikki Linnakangas > wrote: >> Maybe the WAL record you're looking at is a full-page image? A record with a >> full-page image includes a verbatim copy of the page, and the individual >> tuple is omitted in that case. > It is? I thought full

Re: [HACKERS] WAL, xl_heap_insert and tuple oid mystry

Heikki Linnakangas writes: > On 12.04.2011 19:42, jagan wrote: >> In general, why is OID of a tuple relegated as just another tuple >> data, when it can replace xl_heaptid as a much more stable tuple >> identifier. > Possibly. On the other hand, another common complaint is that PostgreSQL > writ

Re: [HACKERS] WAL, xl_heap_insert and tuple oid mystry

(2011/04/13 8:34), Tom Lane wrote: > Greg Stark writes: >> Doesn't pg_lesslog depend on this? > > One hopes not. AFAIK it's safe because pg_lesslog removes full-page image only when it has enough information for substitute incremental log. For example of XLOG_HEAP_INSERT, pg_lesslog generates i

Re: [HACKERS] POSIX shared memory redux

"A.M." writes: > On Apr 11, 2011, at 7:13 PM, Tom Lane wrote: >> Robert Haas writes: >>> I mean I'm not convinced that fcntl() locking will be as reliable. >> I'm not either. Particularly not on NFS. > Is there an example of a recent system where fcntl is broken (ignoring NFS)? Well, the fund