On Wed, 2008-11-12 at 16:25 -0500, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> 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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
