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