Re: Lazy xid assignment V4 - Mailing list pgsql-patches
From | Florian G. Pflug |
---|---|
Subject | Re: Lazy xid assignment V4 |
Date | |
Msg-id | 46DE960B.9070501@phlo.org Whole thread Raw |
In response to | Re: Lazy xid assignment V4 (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Lazy xid assignment V4
|
List | pgsql-patches |
Tom Lane wrote: > "Florian G. Pflug" <fgp@phlo.org> writes: >> Here is an updated patch, following the discussion. >> The patch can be found at: http://soc.phlo.org/lazyxidassign.v4.patch > > I've been working through this, and found a couple items that seem like > judgment calls: > > * Is there a good reason for formatting VXIDs as %d/%X rather than > %d/%u? There are no other columns in pg_locks that we use hex for, > so this seems a bit jarring. The reason was the desire not to bloat the string length unnecessarily. Since the first part is now %d anyways, it only really saves 2 bytes, though... > * What is the rationale for keeping the transaction column in pg_locks? > The useful uniqueness/join column will be virtualtransaction. I don't > see a very strong backwards-compatibility argument for keeping it, > because any code that depends on it being there probably thinks it's a > unique key, which it cannot be anymore. > > One could actually make an argument to rename the virtualtransaction > column as transaction. This will avoid breaking client code that thinks > that the transaction column is a unique key and isn't too wedded to the > assumption that the contents look like an integer. If it is so wedded, > it's most likely busted anyway by the possibility that the column is > null... Wouldn't code that assumes that transaction is "not null" be broken already, because of session locks? I left it there because they only way to get it back if we remove it is to join pg_locks on itself. Thats quite a lot of work - both in terms of typing and CPU cycles to just get that one column. I felt that if we remove the holder's xid from pg_locks, we ought to add it pg_stat_activity, probably along with the virtual transaction id. I actually wanted to do this, but then didn't because currently pg_stat_activity is rather tightly bound to the stats collector. Adding random other values seemes like a bit of a hack... However, none of these are very strong reasons - certainly weaker than doing what ensures to cause the least confusion. I'm therefore starting to think that we should remove transaction, and keep the name virtualtransaction for the VXID. That will ensure that clients who *do* rely on pg_locks and the "transaction" column (which will be few, I guess) at least fail early and visibly, instead of producing bogus results... If we go ahead, and rename virtualtransaction to transaction, I think we should at least put some non-numeric character in front of the virtualtransaction. Most language's string-to-integer functions will happily convert "<number><string>" to the integer <number>. So if they indeed treat virtualtransaction as something int-like, they'd silently use only the backendId instead of the full VXID. greetings, Florian Pflug
pgsql-patches by date: