Skip site navigation (1) Skip section navigation (2)

Re: WAL logging of heap_mark4update

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: WAL logging of heap_mark4update
Date: 2005-01-16 20:01:41
Message-ID: 19260.1105905701@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Heikki Linnakangas <hlinnaka(at)iki(dot)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

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-01-16 20:11:37
Subject: Re: Much Ado About COUNT(*)
Previous:From: Heikki LinnakangasDate: 2005-01-16 19:51:06
Subject: Re: WAL logging of heap_mark4update

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group