On Sun, Mar 4, 2012 at 2:41 PM, Heikki Linnakangas
<heikki.linnakan...@enterprisedb.com> wrote:
> Hmm, I think I see how that can happen:
>
> 0. A heap page has its bit set in visibility map to begin with
>
> 1. A heap tuple is inserted/updated/deleted. This clears the VM bit.
> 2. time passes, and more WAL is generated
> 3. The page is vacuumed, and the visibility map bit is set again.
Note that on 9.0.X, which Christophe is using, the setting of the
visibility map bit in step #3 is not WAL-logged.
> In the standby, this can happen while replaying the WAL, if you restart the
> standby so that some WAL is re-replayed:
>
> 1. The update of the heap tuple is replayed. This clears the VM bit.
> 2. The VACUUM is replayed, setting the VM bit again, and updating the VM
> page's LSN.
Therefore I think this won't happen either, on that version. Do we
somehow emit an FPI for the VM page?
> 3. Shutdown and restart standby
> 4. The heap update is replayed again. This again clears the VM bit, but does
> not set the LSN
>
> If the VM page is now evicted from the buffer cache, you get the WARNING you
> saw, because the page is dirty, yet its LSN is beyond the current point in
> recovery.
>
> AFAICS that's totally harmless, but the warning is quite alarming, so we'll
> have to figure out a way to fix that. Not sure how; perhaps we need to set
> the LSN on the VM page when the VM bit is cleared, but I don't remember off
> the top of my head if there was some important reason why we don't do that
> currently.
I suspect that it was never done just because there was no clear
benefit, since heap_{insert,update,delete} all clear the bit
regardless of the page LSN. But this might be a reason to do it. I
can't swear it's safe, though, although I also can't see why it
wouldn't be. Note also that 9.2devel behaves quite differently than
previous releases: every visibilitymap_set is WAL-logged and bumps the
vm page's LSN; whereas in prior releases no WAL record is emitted and
the vm page's LSN is advanced to the heap page's LSN if it lags it.
So we'd better think pretty carefully before assuming that any logic
about what is safe here is true for all branches.
--
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
