> 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
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
No comments:
Post a Comment