VirtualXactLockTableInsert

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.com
PostgreSQL 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.com
PostgreSQL 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