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 = txid_current()::integer > > which of course starts to fail with "integer out of range" as soon as > txid_current() gets past 2^31. Right now, since there is no cast > between xid and any integer type, and no comparison operator except the > dubious xideqint4 one, the only way we could fix this is something > like > > where transactionid::text = (txid_current() % (2^32))::text > > which is surely pretty ugly. Is it worth doing something less ugly? > I'm not sure if there are any other use-cases for this type of > comparison, but if there are, seems like it would be sensible to invent > a function along the lines of > > txid_from_xid(xid) returns bigint > > that plasters on the appropriate epoch value for an > assumed-to-be-current-or-recent xid, and returns something that squares > with the txid_snapshot functions. Then the test could be coded without > kluges as > > where txid_from_xid(transactionid) = txid_current() > > Thoughts?
Well, the mod-2^32 arithmetic doesn't bother me, but if you're feeling motivated to invent txid_from_xid() I think that would be fine, too. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
