On Tue, Nov 30, 2010 at 10:43 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: >> 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
