Обсуждение: 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