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.
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Jeff Davis||Date: 2011-06-23 02:40:01|
|Subject: Re: crash-safe visibility map, take five|
|Previous:||From: Bruce Momjian||Date: 2011-06-23 01:54:23|
|Subject: Re: pg_upgrade version check improvements and small
pgsql-committers by date
|Next:||From: Tom Lane||Date: 2011-06-23 03:05:25|
|Subject: pgsql: Undo overly enthusiastic de-const-ification.|
|Previous:||From: Bruce Momjian||Date: 2011-06-23 00:49:06|
|Subject: pgsql: In pg_upgrade,check that the binary and data directories are th|