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

From Robert Haas
Subject Re: [COMMITTERS] pgsql: Make the visibility map crash-safe.
Date
Msg-id BANLkTi=gfQodjQGRxPUOcHon=dvW=LZ76Q@mail.gmail.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Make the visibility map crash-safe.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [COMMITTERS] pgsql: Make the visibility map crash-safe.
List pgsql-hackers
On Wed, Jun 22, 2011 at 9:12 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Jun 22, 2011 at 6:55 AM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.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

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade version check improvements and small fixes
Next
From: Jeff Davis
Date:
Subject: Re: crash-safe visibility map, take five