Thread: VirtualXactLockTableInsert
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? 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. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
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
Simon Riggs <simon@2ndquadrant.com> writes:
> In cases where we know we will assign a real xid, can we just skip the
> assignment of the virtual xid completely?
Even if we could do this I doubt it would be a good idea. It'd destroy
the invariant that all transactions have a vxid, which at the very least
would create naming problems.
regards, tom lane
On Fri, 2008-06-27 at 18:00 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > In cases where we know we will assign a real xid, can we just skip the > > assignment of the virtual xid completely? > > Even if we could do this I doubt it would be a good idea. It'd destroy > the invariant that all transactions have a vxid, which at the very least > would create naming problems. Ahh, no, I meant go straight to assigning a real xid, to avoid the wasted effort in inserting a vxid *and* a real xid. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
On Fri, 2008-06-27 at 17:44 +0200, Florian G. Pflug wrote: > 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). Thanks, So there is no attempt to migrate the vxid lock queue onto the xid lock queue because it doesn't matter now/yet. That seems fragile, but as long as we know about it we're OK. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
Simon Riggs <simon@2ndquadrant.com> writes:
> So there is no attempt to migrate the vxid lock queue onto the xid lock
> queue because it doesn't matter now/yet. That seems fragile, but as long
> as we know about it we're OK.
It never will matter, because vxids and xids are unrelated.
regards, tom lane