Simon Riggs wrote:
> When we move from having a virtual xid to having a real xid I don't
> see any attempt to re-arrange the lock queues. Surely if there are
> people waiting on the virtual xid, they must be moved across to wait
> on the actual xid? Otherwise the locking queue will not be respected
> because we have two things on which people might queue. Anybody
> explain that?
Locks on real xids serve a different purpose than locks on virtual xids.
Locks on real xids are used to wait for transaction who touched a
certain tuple (in which case they certainly must have acquired a real
xid) to end. Locks on vxids on the other hand are used to wait for the
ending of transactions which either hold a certain lock or use a
snapshot with a xmin earlier than some point in time.
indexcmds.c is the only place where VirtualXactLockTableWait() is used -
the concurrent index creation needs to wait for all transactions to end
which either might not know about the index (after phase 1 and 2), or
who might still see tuples not included in the index (before marking the
index valid).
> In cases where we know we will assign a real xid, can we just skip
> the assignment of the virtual xid completely? For example, where an
> implicit transaction is started by a DML statement. Otherwise we have
> to wait for 2 lock table inserts, not just one.
A more general solution would be to get rid of vxid locks completly.
This is possible if we figure out a way to handle the first two waiting
phases or concurrent index builds in another way. One idea I had for
approaching this was to extend the lock manager by adding some sort of
WaitForCurrentLockHolders(LockTag) function. I felt (and still feel)
feel I didn't understand the locking code well enough to start hacking
it though, and Tom didn't like the idea either. His argument was that it
wasn't clear how deadlock detection would cope with such a facility IIRC.
regards, Florian Pflug
