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