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

Re: WAL logging of heap_mark4update

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 19:51:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sat, 15 Jan 2005, Tom Lane wrote:

> Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)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

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2005-01-16 20:01:41
Subject: Re: WAL logging of heap_mark4update
Previous:From: Manfred KoizarDate: 2005-01-16 19:49:45
Subject: Re: Much Ado About COUNT(*)

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