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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
