v4-0001-Fix-stuck-shutdown-due-to-unflushed-records.patch
application/octet-stream
Filename: v4-0001-Fix-stuck-shutdown-due-to-unflushed-records.patch
Type: application/octet-stream
Part: 1
Patch
Format: format-patch
Series: patch v4-0001
Subject: Fix stuck shutdown due to unflushed records
| File | + | − |
|---|---|---|
| src/backend/access/transam/xact.c | 12 | 1 |
From a2310f65695d9481354100a503c92b7cd8255a2d Mon Sep 17 00:00:00 2001
From: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
Date: Tue, 24 Feb 2026 09:24:48 +0100
Subject: Fix stuck shutdown due to unflushed records
Shutdown sequence may be stuck indefinitely under the following
circumstances:
- Data checksums is enabled
- A logical replication walsender is running
- A select in an explicit transaction tries to prune a full heap page,
wrote a FPI_FOR_HINT record which crosses the page boundary
- The select is rollbacked (or killed)
- 'pg_ctl stop' is sent
The FPI_FOR_HINT record is likely going to be a contrecord and starts a
new page. However, as the select is rollbacked, XLogSetAsyncXactLSN
isn't called to advance the LSN to include this record.
When the checkpointer starts ShutdownXLOG(), all walsenders will be
notified to stop. However, the logical replication walsender will be
stuck in the following infinite loop:
- Tries to read the last FPI_FOR_HINT record
- The page with the record header is read
- tot_len > len, the record needs to be reassembled
- Tries to read the next page containing the rest of the record. It fails since this page was never written.
- xlog reader state is reset with XLogReaderInvalReadState
- It goes back to the start of WalSndLoop's loop
There are some attempts done by the walsender to flush the WAL using
XLogBackgroundFlush. However, XLogBackgroundFlush only writes completed
blocks, or up to the latest known async lsn.
Since the select was rollbacked, XLogBackgroundFlush doesn't flush the
next partial page.
This patch fixes the issue by advancing the async LSN, even when the
transaction doesn't have an assigned xid. This allows
XLogBackgroundFlush to write the necessary partial page when called by
the walsender.
---
src/backend/access/transam/xact.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c
index eba4f063168..1786b397769 100644
--- a/src/backend/access/transam/xact.c
+++ b/src/backend/access/transam/xact.c
@@ -1786,8 +1786,19 @@ RecordTransactionAbort(bool isSubXact)
if (!TransactionIdIsValid(xid))
{
/* Reset XactLastRecEnd until the next transaction writes something */
- if (!isSubXact)
+ if (!isSubXact && XactLastRecEnd != 0)
+ {
+ /*
+ * Even if no xid was assigned, some records may have been written
+ * in the WAL. Report the latest async LSN, so that the WAL writer
+ * knows to flush those records. This is important when shutting
+ * down, walsender may use XLogBackgroundFlush to trigger pending
+ * WAL to be written out. If they're not tracked by async xact
+ * lsn, they won't be written by XLogBackgroundFlush.
+ */
+ XLogSetAsyncXactLSN(XactLastRecEnd);
XactLastRecEnd = 0;
+ }
return InvalidTransactionId;
}
--
2.52.0