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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
