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

Re: crash-safe visibility map, take three

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: crash-safe visibility map, take three
Date: 2010-12-01 16:44:12
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On 01.12.2010 18:40, Tom Lane wrote:
> Robert Haas<robertmhaas(at)gmail(dot)com>  writes:
>> As far as I can tell, there are basically two viable solutions on the
>> table here.
>> 1. Every time we observe a page as all-visible, (a) set the
>> PD_ALL_VISIBLE bit on the page, without bumping the LSN; (b) set the
>> bit in the visibility map page, bumping the LSN as usual, and (c) emit
>> a WAL record indicating the relation and block number.  On redo of
>> this record, set both the page-level bit and the visibility map bit.
>> The heap page may hit the disk before the WAL record, but that's OK;
> Um, no it isn't.  Suppose the heap page gets to disk but we crash before
> the WAL record does.  Now we have a persistent state where the heap page
> is marked PD_ALL_VISIBLE but the corresponding VM bit is not set.  The
> VM bit will never become set, either, because operations on the heap
> page will see PD_ALL_VISIBLE and assume it already is set.  This state
> of affairs might be acceptable from a correctness standpoint, but not
> from a performance standpoint.

The next vacuum will fix it. We already handle that. It's no different 
from the situation where neither change makes it to the disk.

   Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2010-12-01 16:48:03
Subject: Re: crash-safe visibility map, take three
Previous:From: Tom LaneDate: 2010-12-01 16:43:39
Subject: Re: crash-safe visibility map, take three

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