Re: GetCurrentVirtualXIDs() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: GetCurrentVirtualXIDs()
Date
Msg-id 20844.1238787966@sss.pgh.pa.us
Whole thread Raw
In response to GetCurrentVirtualXIDs()  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: GetCurrentVirtualXIDs()  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> No need to wait for idle-in-transaction sessions during index builds.
> GetCurrentVirtualXIDs() specifically *includes* backends that have
> proc->xmin == InvalidTransactionId (0), but I'm not sure why.

On further consideration, this patch is simply *wrong*, and would still
be wrong even if we changed GetCurrentVirtualXIDs to take ProcArrayLock
exclusive instead of shared.

If a backend currently has no snapshot, then if it takes a snapshot
immediately after we finish running GetCurrentVirtualXIDs, it will
set its proc->xmin (and that of the snapshot) to the oldest currently
running XID.  There is no reason to assume that that value is >=
limitXmin, which is what you propose we do.

A safe modification of the patch would be to determine the oldest
running XID and exclude xmin-less VXIDs when that number is greater
than limitXmin.  However, I think that that would be pretty useless:
for the one current use of GetCurrentVirtualXIDs, limitXmin is the
xmax of the snapshot we used for the index build, and we can assume
that our *own* XID is less than that, never mind anyone else's.

So I don't think this works...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: reloptions with a "namespace"
Next
From: Tom Lane
Date:
Subject: Re: reloptions with a "namespace"