Re: GetCurrentVirtualXIDs() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: GetCurrentVirtualXIDs()
Date
Msg-id 24398.1238797699@sss.pgh.pa.us
Whole thread Raw
In response to Re: GetCurrentVirtualXIDs()  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: GetCurrentVirtualXIDs()
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> However, the basic premise is that idle-in-transaction sessions do not
> need to block index builds.

[ thinks for awhile... ]  Actually, I believe that your premise is
correct; the problem is with your proof ;-).  Considering only the
xmins is insufficient to prove that this is safe; but as we know,
xmin comparisons are an oversimplification of snapshot relationships.

What the indexcmds.c comments say are
  * Now take the "reference snapshot" that will be used by validate_index()  * to filter candidate tuples.  Beware!
Theremight still be snapshots in  * use that treat some transaction as in-progress that our reference  * snapshot
treatsas committed.  If such a recently-committed transaction  * deleted tuples in the table, we will not include them
inthe index; yet  * those transactions which see the deleting one as still-in-progress will  * expect them to be there
oncewe mark the index as valid.
 

and then (after validate_index)
  * The index is now valid in the sense that it contains all currently  * interesting tuples.  But since it might not
containtuples deleted just  * before the reference snap was taken, we have to wait out any  * transactions that might
haveolder snapshots.  Obtain a list of VXIDs  * of such transactions, and wait for them individually.
 

The important point here is that we only have to wait for transactions
that might have snapshots older than our reference snapshot.  A
transaction with no snapshots (evidenced by its xmin = 0), a fortiori,
has no older snapshots.  And even if it's in process of taking one when
GetCurrentVirtualXIDs examines it, it cannot conclude that any
transaction that our reference snap saw as committed is still running.
(This is true even if the other guy started his GetSnapshotData before
we did and has somehow managed to not finish yet.  In that case, he's
been holding ProcArrayLock shared the whole time, and no transaction
could have exited "running" state at all.)

So on third thought I think the patch logic is sound; but I think that
as documentation we had better add another bool parameter to
GetCurrentVirtualXIDs indicating whether it's okay to ignore procs
with xmin = 0.  It seems at least possible that some future usage of
GetCurrentVirtualXIDs might need that done differently.

(This logic also shows that we need not actually wait for a transaction
to *complete*; as soon as it's gone idle and has no snapshots, we could
disregard it.  But that would take a much more invasive patch to
implement, so it's definitely too late for 8.4.)

Comments?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Saner interval hash function
Next
From: Jaime Casanova
Date:
Subject: Re: Saner interval hash function