On 2021/09/08 22:41, Fujii Masao wrote:
So probably we reached the consensus that something like the attached patch
(XLogArchiveCheckDone_walfile_xlog_switch.patch) is enough for the corner
case where walreceiver fails to create .ready file of WAL file including
XLOG_SWITCH?
I attached the patch again, just in the case.
Sounds convincing. Ok, I agree to that.
So barring any objection, I will commit the patch
and back-patch it to all supported version.
Pushed. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/src/backend/access/transam/xlog.c
b/src/backend/access/transam/xlog.c
index e51a7a749d..6046e24f0f 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7392,6 +7392,27 @@ StartupXLOG(void)
/* Handle interrupt signals of startup process
*/
HandleStartupProcInterrupts();
+ /*
+ * In standby mode, create an archive
notification file of a
+ * WAL segment if it includes an XLOG_SWITCH
record and its
+ * notification file has not been created yet.
This is
+ * necessary to handle the corner case that
walreceiver may
+ * fail to create such notification file if it
exits after it
+ * receives XLOG_SWITCH record but while it's
receiving the
+ * remaining bytes in the segment. Without this
handling, WAL
+ * archiving of the segment will be delayed
until subsequent
+ * checkpoint creates its notification file
when removing it
+ * even though it can be archived soon.
+ */
+ if (StandbyMode && record->xl_rmid ==
RM_XLOG_ID &&
+ (record->xl_info & ~XLR_INFO_MASK) ==
XLOG_SWITCH)
+ {
+ char
xlogfilename[MAXFNAMELEN];
+
+ XLogFileName(xlogfilename, curFileTLI,
readSegNo, wal_segment_size);
+ XLogArchiveCheckDone(xlogfilename);
+ }
+
/*
* Pause WAL replay, if requested by a
hot-standby session via
* SetRecoveryPause().
