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

Re: [COMMITTERS] pgsql: Make the visibility map crash-safe.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Robert Haas <rhaas(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Make the visibility map crash-safe.
Date: 2011-06-23 02:23:39
Message-ID: BANLkTi=gfQodjQGRxPUOcHon=dvW=LZ76Q@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On Wed, Jun 22, 2011 at 9:12 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Jun 22, 2011 at 6:55 AM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> On 22.06.2011 06:05, Robert Haas wrote:
>>>
>>> Second, when inserting, updating, or deleting
>>> a tuple, we can no longer get away with clearing the visibility map
>>> bit after releasing the lock on the corresponding heap page, because
>>> an intervening crash might leave the visibility map bit set and the
>>> page-level bit clear.
>>
>> heap_update seems to still do that.
>
> Aw, crap.  I'll take another look.

Well, it seems I didn't put nearly enough thought into heap_update().
The fix for the immediate problem looks simple enough - all the code
has been refactored to use the new API, so the calls can be easily be
moved into the critical section (see attached).  But looking at this a
little more, I see that heap_update() is many bricks short of a load,
because there are several places where the buffer can be unlocked and
relocked, and we don't recheck whether the page is all-visible after
reacquiring the lock.  So I've got some more work to do here.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment: heap-update-vm-fix.patch
Description: application/octet-stream (1.1 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Jeff DavisDate: 2011-06-23 02:40:01
Subject: Re: crash-safe visibility map, take five
Previous:From: Bruce MomjianDate: 2011-06-23 01:54:23
Subject: Re: pg_upgrade version check improvements and small fixes

pgsql-committers by date

Next:From: Tom LaneDate: 2011-06-23 03:05:25
Subject: pgsql: Undo overly enthusiastic de-const-ification.
Previous:From: Bruce MomjianDate: 2011-06-23 00:49:06
Subject: pgsql: In pg_upgrade,check that the binary and data directories are th

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