Simon Riggs <[EMAIL PROTECTED]> 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.
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 Fri, 2008-06-27 at 18:00 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> 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 i
Simon Riggs <[EMAIL PROTECTED]> 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 le
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
becau
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 thing
