Thread: WAL logging of heap_mark4update

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?  If it isn't, maybe
it's a good idea to update the comment.  I don't really understand the
issue: I assume that since the marking changes the page on disk, it
would need to be WAL-logged; however, since the change needs not be
permanent because the lock doesn't need to be preserved across a crash, 
we just skip it.

I think the comment was made assuming that savepoints would be
implemented using REDO, and that in our multiple-Xid design does not
hold.  So it's inaccurate.  Am I right?


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?

-- 
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"Saca el libro que tu religi�n considere como el indicado para encontrar la
oraci�n que traiga paz a tu alma. Luego rebootea el computador
y ve si funciona" (Carlos Ducl�s)

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 ...)

> I think the comment was made assuming that savepoints would be
> implemented using REDO,

I think the same.

> 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.
        regards, tom lane

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

Heikki Linnakangas <hlinnaka@iki.fi> 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