Fix assertion failure when updating full_page_writes for checkpointer.

When the checkpointer receives a SIGHUP signal to update its configuration,
it may need to update the shared memory for full_page_writes and need to
write a WAL record for it.  Now, it is quite possible that the XLOG
machinery has not been initialized by that time and it will lead to
assertion failure while doing that.  Fix is to allow the initialization of
the XLOG machinery outside critical section.

This bug has been introduced by the commit 2c03216d83 which added the XLOG
machinery initialization in RecoveryInProgress code path.

Reported-by: Dilip Kumar
Author: Dilip Kumar
Reviewed-by: Michael Paquier and Amit Kapila
Backpatch-through: 9.5
Discussion: https://postgr.es/m/CAFiTN-u4BA8KXcQUWDPNgaKAjDXC=C2whnzBM8TAcv=stckYUw@mail.gmail.com
This commit is contained in:
Amit Kapila 2018-09-28 11:50:17 +05:30
parent 92a0342a90
commit a86bf6057e
1 changed files with 9 additions and 1 deletions

View File

@ -9701,6 +9701,7 @@ void
UpdateFullPageWrites(void)
{
XLogCtlInsert *Insert = &XLogCtl->Insert;
bool recoveryInProgress;
/*
* Do nothing if full_page_writes has not been changed.
@ -9712,6 +9713,13 @@ UpdateFullPageWrites(void)
if (fullPageWrites == Insert->fullPageWrites)
return;
/*
* Perform this outside critical section so that the WAL insert
* initialization done by RecoveryInProgress() doesn't trigger an
* assertion failure.
*/
recoveryInProgress = RecoveryInProgress();
START_CRIT_SECTION();
/*
@ -9732,7 +9740,7 @@ UpdateFullPageWrites(void)
* Write an XLOG_FPW_CHANGE record. This allows us to keep track of
* full_page_writes during archive recovery, if required.
*/
if (XLogStandbyInfoActive() && !RecoveryInProgress())
if (XLogStandbyInfoActive() && !recoveryInProgress)
{
XLogBeginInsert();
XLogRegisterData((char *) (&fullPageWrites), sizeof(bool));