On Wed, Jun 22, 2011 at 9:12 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Jun 22, 2011 at 6:55 AM, Heikki Linnakangas > <heikki.linnakan...@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
heap-update-vm-fix.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
