"Pavan Deolasee" <pavan.deolasee@gmail.com> writes: > On 9/4/07, Florian G. Pflug <fgp@phlo.org> wrote: >> Here is an updated patch, following the discussion. >> The patch can be found at: http://soc.phlo.org/lazyxidassign.v4.patch >> (I seems I still can't get attachments through to this list) >> > I haven't been able to follow the discussions here, but do I need to worry > about its interaction with HOT ? There will likely be some minor patch-merging problems, but AFAICT there are no semantic conflicts to worry about. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster

"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. * 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... Comments? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org

"Florian G. Pflug" <fgp@phlo.org> writes: > 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... Barring other objections, I'll do it that way. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly

"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 seems I still can't get attachments through to this list) Applied with revisions --- mostly cosmetic, but there were a couple of things that seemed really broken. In particular, I didn't trust at all your use of struct assignment to copy VXIDs into and out of PGPROC. I believe that the C compiler is entitled to implement struct assignment by bytewise memcpy, for instance, and so it wouldn't be atomic. The LocalTransactionId can be fetched or stored atomically, but you have to write it as an integer assignment to be sure that that's what happens. I also fixed sequence.c to not force XID assignment --- it can perfectly well use the LocalTransactionId for what it's doing. Also, I didn't add the proposed regression test, as it seems much too fragile --- concurrent autovacuum activity would make it fail, for instance. There are a couple of loose ends, which I'll post about separately on -hackers. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings

Robert Treat <xzilla@users.sourceforge.net> writes: > ISTM that by removing the transaction column, there is no way to see the XID > for relations thats have been updated (which by definition will have locks on > them). Am I mis-reading the docs, or have we lost that functionality? Huh? What do you mean by "XID for relations that have been updated"? Relations don't have XIDs. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings

Andrew Dunstan <andrew@dunslane.net> writes: > Florian G. Pflug wrote: >> So, in essence, you get the old pg_locks format back by doing >> select l1.*, l2.transactionid as "transaction" from pg_locks l1, >> pg_locks l2 >> where l1.vxid = l2.vxid and l2.locktype = 'transaction' >> and l2.mode='exclusive' and l2.granted=true. You'd want some sort of left join, no doubt, else you're not going to see transactions that have not got an XID. > or make it a system view? That would be a bit silly. If there's actually still a use-case for the XID column then we should just put it back. I don't actually see a reasonable use-case for it though. As Florian points out, you can get it if you really need it --- but that view is already annoyingly wide, and I'm not eager to burden it with columns that are usually useless. Also, I still agree with Florian's earlier argument that we should deliberately break any code that's depending on the transaction column. Any such code is unlikely to be prepared for the column containing nulls. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly