"Simon Riggs" <[EMAIL PROTECTED]> writes:
> I agree we could get this to Just Work by altering
> HeapTupleSatisfies...() functions so that their first test is
> if (TransactionIdIsCurrentTransactionId(xvac))
> rather then
> if (!(tuple->t_infomask & HEAP_XMIN_COMMITTED))
Huh? That doesn't make any sense at all. xvac wouldn't normally be
valid.
I don't want to put TransactionIdIsCurrentTransactionId into the main
path of the tqual routines if at all possible; it's not an especially
cheap test, particularly if deeply nested in subtransactions. My
thought was that for SatisfiesSnapshot, you'd fall through the first
big chunk if XMIN_COMMITTED is set and then fail the XidInSnapshot test.
Then a TransactionIdIsCurrentTransactionId test could be added in that
fairly-unusual failure path, where it wouldn't slow the main path of
control. Something like
if (XidInSnapshot(HeapTupleHeaderGetXmin(tuple), snapshot))
{
if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmin(tuple)))
{
if (HeapTupleHeaderGetCmin(tuple) >= snapshot->curcid)
return false; /* inserted after scan started */
}
else
return false; /* treat as still in progress */
}
This would require rejiggering snapshots to include our own xid, see
comment for XidInSnapshot. That would add some distributed cost to
executions of XidInSnapshot for recently-committed tuples, but it would
avoid adding any cycles to the path taken for tuples committed before
the xmin horizon, which is the normal case that has to be kept fast.
Haven't looked at whether an equivalent hack is possible for the other
tqual routines.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
