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.80501@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