Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> On Sat, 15 Jan 2005, Tom Lane wrote:
>> Right. The 2PC connection is another reason to do it that way --- 2PC
>> would require some way to save locks anyhow, and it'd be nice if there
>> were only one mechanism to deal with not two.
> AFAICS, heap_mark4update calls XactLockTableWait for the updating
> transaction, and XactLockTableWait uses LockAcquire to do the waiting.
Right, but the marking on the row is essential as well. If we lost that
marker in a crash-and-restart after precommitting the transaction that
has locked the row, then another transaction could come along and think
that it can take ownership of the row, when in reality the precommitted
transaction should still be considered to have a lock on the row. So
it's not enough to remember only the XactLockTableWait lock.
(BTW, I think that XactLockTableWait is *only* used for
heap_mark4update, so we could get rid of that too, thereby saving one
lock acquisition per transaction ...)
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
