On Tue, Nov 30, 2010 at 10:43 AM, Heikki Linnakangas
>> It seems like you'll need to hold some kind of lock between the time
>> you examine RedoRecPtr and the time you actually examine the bit.
>> WALInsertLock in shared mode, maybe?
> It's enough to hold an exclusive lock on the visibility map page. You have
> to set the bit first, and then check RedoRecPtr, and if it changed, write
> the XLOG record before releasing the lock. If RedoRecPtr changes any time
> before we check RedoRecPtr, we'll write the XLOG record so we're safe. If it
> changes after that, we're safe because the checkpoint will flush the updated
> heap page and visibility map page.
Brilliant. I assume that we need to call GetRedoRecPtr() after taking
the exclusive lock on the page, though?
> Yeah, possibly. It also means that the set bits will not propagate to
> standby servers, though.
That's definitely sucky, but in some ways it would be more complicated
if they did, because I don't think all-visible on the master implies
all-visible on the standby.
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Alexey Klyukin||Date: 2010-11-30 16:00:23|
|Subject: Another proposal for table synonyms|
|Previous:||From: Heikki Linnakangas||Date: 2010-11-30 15:53:25|
|Subject: Re: crash-safe visibility map, take three|