Tom Lane wrote: > This seems like a pretty lousy place to do it, first because of the > contention hit from holding that high-traffic lock any longer than > necessary, and second because every added chance for error between > ExtendCLOG() and TransactionIdAdvance(ShmemVariableCache->nextXid) > gives us another way to fail in the way recently mentioned by Joe > Conway: > http://archives.postgresql.org/message-id/4dbe4e7d.80...@joeconway.com > Even if it's actually necessary to set up that data structure while > holding XidGenLock, I would *really* like the call to not be > exactly where it is. On a quick scan, I can't see any reason this couldn't be moved down to just above the return. I think the reason I dropped it where I did was simply that it was where we seemed to be letting other parts of the system know about the new xid, so I was going for consistency. I want to double-check this when I'm a little more awake, but my I don't think that anything will be doing anything in the predicate locking area where xid would matter until after the return from this function. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
