Re: [HACKERS] Regression tests fail once XID counter exceeds 2 billion

2012-08-16 Thread Bruce Momjian
On Wed, Nov 16, 2011 at 07:08:27PM -0500, Tom Lane wrote: I wrote: Simon Riggs si...@2ndquadrant.com writes: We need a function called transactionid_current() so a normal user can write select virtualtransaction from pg_locks where transactionid = transactionid_current() and

Re: [HACKERS] Regression tests fail once XID counter exceeds 2 billion

2011-11-16 Thread Tom Lane
I wrote: Simon Riggs si...@2ndquadrant.com writes: We need a function called transactionid_current() so a normal user can write select virtualtransaction from pg_locks where transactionid = transactionid_current() and have it just work. That would solve that one specific use-case. The

Re: [HACKERS] Regression tests fail once XID counter exceeds 2 billion

2011-11-15 Thread Simon Riggs
On Sun, Nov 13, 2011 at 11:16 PM, Tom Lane t...@sss.pgh.pa.us wrote: While investigating bug #6291 I was somewhat surprised to discover $SUBJECT.  The cause turns out to be this kluge in alter_table.sql:        select virtualtransaction        from pg_locks        where transactionid =

Re: [HACKERS] Regression tests fail once XID counter exceeds 2 billion

2011-11-15 Thread Tom Lane
Simon Riggs si...@2ndquadrant.com writes: We need a function called transactionid_current() so a normal user can write select virtualtransaction from pg_locks where transactionid = transactionid_current() and have it just work. That would solve that one specific

Re: [HACKERS] Regression tests fail once XID counter exceeds 2 billion

2011-11-14 Thread Robert Haas
On Sun, Nov 13, 2011 at 6:16 PM, Tom Lane t...@sss.pgh.pa.us wrote: While investigating bug #6291 I was somewhat surprised to discover $SUBJECT.  The cause turns out to be this kluge in alter_table.sql:        select virtualtransaction        from pg_locks        where transactionid =

[HACKERS] Regression tests fail once XID counter exceeds 2 billion

2011-11-13 Thread Tom Lane
While investigating bug #6291 I was somewhat surprised to discover $SUBJECT. The cause turns out to be this kluge in alter_table.sql: select virtualtransaction from pg_locks where transactionid = txid_current()::integer which of course starts to fail with integer out of