Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>> This guarantee enables a few optimizations. First, as you say in the
>> comments, finding the largest xid when committing becomes trivial. But more
>> important, if we can assume that the proc array xid cache is always
>> sorted, we can get ride of the exclusive lock during subxact abort.
>
> No, we can't, because subxact abort still has to advance latestCompletedXid.
I don't think so. I didn't notice that when initially reading your patch -
but it seems that updating latestCompletedXid during subxact abort is actually
worsening performance (only very slightly, though).
The whole point of updating latestCompletedXid when aborting a toplevel xact
is to prevent the following corner case.
.) Some transaction commits
.) Only readonly transactions
(all xmins = xmaxs = latestCompletedXid+1)
.) One large Transaction that Aborts
(xid = GetNewTransactionId() = latestCompletedXid+1)
.) Only readonly transactions for a long period again.
all xmins = xmaxs = latestCompletedXid+1
If the ABORT didn't update latestCompletedXid, than we'd not be able to remove
rows created by that one large transactions (which aborted), because all the
xmins would still be latestCompletedXid+1, which is not > the xid of the
aborted transaction.
So we updating latestCompletedXid is only *necessary* durings COMMITS - during
ABORTS it's just done for efficiency reasons.
But for subtransactions, there is no efficiency gain at all, because the
toplevel xid already bounds the xmin. In fact, updating latestCompletedXid
during subxact moves the snapshot's xmax unnecessary far into the future,
which leads to larger snasphots, meaning more cycles spent to scan them.
I do feel that I explained the idea rather badly though in my initial
response to your patch - I'll post (hopefully) better explanation to
the hackers list shortly.
greetings, Florian Pflug