From: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
To: pgsql-bugs@lists.postgresql.org
Cc: Michael Paquier <michael@paquier.xyz>
Subject: [BUG] non archived WAL removed during production crash recovery
Date: Tue, 31 Mar 2020 17:22:29 +0200
Message-ID: <20200331172229.40ee00dc@firost> (raw)
Hello,
A colleague of mine reported an expected behavior.
On production cluster is in crash recovery, eg. after killing a backend, the
WALs ready to be archived are removed before being archived.
See in attachment the reproduction script "non-arch-wal-on-recovery.bash".
This behavior has been introduced in 78ea8b5daab9237fd42d7a8a836c1c451765499f.
Function XLogArchiveCheckDone() badly consider the in crashed recovery
production cluster as a standby without archive_mode=always. So the check
conclude the WAL can be removed safely.
bool inRecovery = RecoveryInProgress();
/*
* The file is always deletable if archive_mode is "off". On standbys
* archiving is disabled if archive_mode is "on", and enabled with
* "always". On a primary, archiving is enabled if archive_mode is "on"
* or "always".
*/
if (!((XLogArchivingActive() && !inRecovery) ||
(XLogArchivingAlways() && inRecovery)))
return true;
Please find in attachment a patch that fix this issue using the following test
instead:
if (!((XLogArchivingActive() && !StandbyModeRequested) ||
(XLogArchivingAlways() && inRecovery)))
return true;
I'm not sure if we should rely on StandbyModeRequested for the second part of
the test as well thought. What was the point to rely on RecoveryInProgress() to
get the recovery status from shared mem?
Regards,
Attachments:
non-arch-wal-on-recovery.bash (application/octet-stream, 943B) download0001-Fix-WAL-retention-during-production-crash-recovery.patch (text/x-patch, 1.1K) download
From aecb5f2de5c9ef3d2e7a4a4f29a7de61f8665373 Mon Sep 17 00:00:00 2001
From: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
Date: Tue, 31 Mar 2020 16:56:40 +0200
Subject: [PATCH] Fix WAL retention during production crash recovery
During crash recovery of a production cluster with archive_mode=on,
XLogArchiveCheckDone() was considering the cluster as inRecovery
without archive_mode=always. Because of this non-arcived WAL and
related .ready files were recycled or removed.
---
src/backend/access/transam/xlogarchive.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/backend/access/transam/xlogarchive.c b/src/backend/access/transam/xlogarchive.cindex d62c12310a..088206ac38 100644--- a/src/backend/access/transam/xlogarchive.c+++ b/src/backend/access/transam/xlogarchive.c@@ -580,7 +580,7 @@ XLogArchiveCheckDone(const char *xlog)
* "always". On a primary, archiving is enabled if archive_mode is "on"
* or "always".
*/
- if (!((XLogArchivingActive() && !inRecovery) ||+ if (!((XLogArchivingActive() && !StandbyModeRequested) ||
(XLogArchivingAlways() && inRecovery)))
return true;
--
2.20.1
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: jgdr@dalibo.com, pgsql-bugs@lists.postgresql.org, michael@paquier.xyz
Subject: Re: [BUG] non archived WAL removed during production crash recovery
In-Reply-To: <20200331172229.40ee00dc@firost>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox