On Tue, 2008-11-11 at 21:57 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On Mon, 2008-11-10 at 19:15 -0500, Tom Lane wrote:
> >> The reason I was thinking about heap_lock_tuple is that it might provide
> >> a suitable defense against that case.
>
> > OK. Lock tuple works OK, but its the unlock that I'm worried about. How
> > would non-transactional un-lock tuple work?
>
> I was imagining that the heap_inplace_update operation would release the
> lock. Is there some problem with the concept?
Not the concept, just the mechanism.
Current tuple lock requestors do XactLockTableWait() which waits until
the lock on the transaction is released and removed from procarray.
The only way I can see to do this is by having another lock type, using
an additional info bit on t_infomask2. If that is set then we just wait
on a tuple lock, rather on the transaction lock. So we would add another
wait case into the heap_lock_tuple(), heap_update() and heap_delete().
Maybe NonXactLockTupleWait().
Requirement is to have anybody placing a non-transactional tuple lock to
already have a lock on relation. We would not need to WAL log this type
of lock, since we will require the lock holder to keep the buffer
pinned. The lock type would not need to be replayed for hot standby,
That OK, or do you see another way?
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support