Re: [HACKERS] xlog min recovery request ... is past current point ...
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
Re: [HACKERS] xlog min recovery request ... is past current point ...
On 03.02.2012 18:32, Christophe Pettus wrote: PostgreSQL 9.0.4: While bringing up a streaming replica, and while it is working its way through the WAL segments before connecting to the primary, I see a lot of messages of the form: 2012-02-01 21:26:13.978 PST,,,24448,,4f2a1e61.5f80,54,,2012-02-01 21:25:53 PST,1/0,0,LOG,0,restored log file 00010DB40065 from archive, 2012-02-01 21:26:14.032 PST,,,24448,,4f2a1e61.5f80,55,,2012-02-01 21:25:53 PST,1/0,0,WARNING,01000,xlog min recovery request DB5/42E15098 is past current point DB4/657FA490,writing block 5 of relation base/155650/156470_vm xlog redo insert: rel 1663/155650/1658867; tid 9640/53 2012-02-01 21:26:14.526 PST,,,24448,,4f2a1e61.5f80,56,,2012-02-01 21:25:53 PST,1/0,0,LOG,0,restored log file 00010DB40066 from archive, All of these are on _vm relations. The recovery completed successfully and the secondary connected to the primary without issue, so: Are these messages something to be concerned over? 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. 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. 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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] xlog min recovery request ... is past current point ...
PostgreSQL 9.0.4: While bringing up a streaming replica, and while it is working its way through the WAL segments before connecting to the primary, I see a lot of messages of the form: 2012-02-01 21:26:13.978 PST,,,24448,,4f2a1e61.5f80,54,,2012-02-01 21:25:53 PST,1/0,0,LOG,0,restored log file 00010DB40065 from archive, 2012-02-01 21:26:14.032 PST,,,24448,,4f2a1e61.5f80,55,,2012-02-01 21:25:53 PST,1/0,0,WARNING,01000,xlog min recovery request DB5/42E15098 is past current point DB4/657FA490,writing block 5 of relation base/155650/156470_vm xlog redo insert: rel 1663/155650/1658867; tid 9640/53 2012-02-01 21:26:14.526 PST,,,24448,,4f2a1e61.5f80,56,,2012-02-01 21:25:53 PST,1/0,0,LOG,0,restored log file 00010DB40066 from archive, All of these are on _vm relations. The recovery completed successfully and the secondary connected to the primary without issue, so: Are these messages something to be concerned over? -- -- Christophe Pettus x...@thebuild.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
