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

Re: crash-safe visibility map, take three

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: crash-safe visibility map, take three
Date: 2010-11-30 16:37:13
Message-ID: 27659.1291135033@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> On 30.11.2010 18:10, Tom Lane wrote:
>> I'm not convinced it works at all.  Consider write intent record,
>> checkpoint, set bit, crash before completing vacuum.  There will be
>> no second intent record at which you could clean up if things are
>> inconsistent.

> That's why you need to check the RedoRecPtr when you set the bit. If it 
> has changed, ie. a checkpoint has happened, the set bit step will write 
> a new intent record.

Oh, you explained the proposal poorly then.  I thought you meant recheck
and write another intent record just once, immediately before sending
the final xlog record.

It still seems rickety and not clearly correct, especially when you
start thinking about all the other constraints we have on xlog behavior
(eg, does this work while taking a base backup).

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Greg SmithDate: 2010-11-30 16:38:13
Subject: Re: Instrument checkpoint sync calls
Previous:From: Tom LaneDate: 2010-11-30 16:33:18
Subject: Re: crash-safe visibility map, take three

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