Re: WAL logging of heap_mark4update

On Sat, 15 Jan 2005, Tom Lane wrote:

> Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
>> Hackers,
>> In access/heap/heapam.c, in heap_mark4update(), there's a comment that
>> states
>
>>     /*
>>      * XLOG stuff: no logging is required as long as we have no
>>      * savepoints. For savepoints private log could be used...
>>      */
>
>> Is this still true in light of 8.0's savepoints?
>
> It isn't.  Since mark4update is simply establishing a lock, which isn't
> going to be held across a system crash anyway, I see no need to WAL-log
> it.  (But hmmm ... to support 2PC we'd probably need to do so ...)

Yes, for 2PC you need to keep all locks over system crash.

>> In any case I'm contemplating changing exclusive row locks to use
>> LockAcquire, and supporting shared row locks using the same mechanism.
>> All this per previous discussion on -hackers.  We could get rid of
>> heap_mark4update if that's done, right?
>
> 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.

I must be missing something. Can someone briefly explain me 
what's special about this locking mechanism, please? How are you planning 
to change it?

- Heikki