Re: Reducing some DDL Locks to ShareLock

On Wed, 2008-11-12 at 16:25 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On Tue, 2008-11-11 at 21:57 -0500, Tom Lane wrote: 
> >> 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.
> 
> Ah, I see.  Yeah, that won't work nicely.
> 
> > The only way I can see to do this is by having another lock type, using
> > an additional info bit on t_infomask2.
> 
> The alternative I was thinking about involved taking an exclusive buffer
> lock on the page containing the tuple to be updated in-place.  The point
> being that you have to examine the old tuple contents and decide whether
> to update after you have lock, not before.  I think this would amount to
> refactoring heap_inplace_update into two operations: fetch/lock and
> update/unlock.  (I guess there should be a third function to release
> without updating, too --- that would really just be an unlock-buffer
> operation, but it'd be better if callers didn't explicitly know that.)
> The callers would probably still use the syscache to obtain the tuple
> address, but they wouldn't rely on it to supply the tuple image.

I'll look into this.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support