On Thu, Feb 26, 2026 at 5:20 PM Fujii Masao <[email protected]> wrote: > Thanks for reporting this issue and for the patch! > > I was able to reproduce the problem on master.
Thanks for the confirmation! > I'm a bit concerned that this approach could cause walwriter to attempt > WAL writes more aggressively in some cases, adding overhead during > normal processing. If the goal is only to prevent shutdown from getting stuck, > instead, would it be sufficient for ShutdownXLOG() to call > XLogSetAsyncXactLSN() just before WalSndWaitStopping()? I did something similar with the first version using XLogFlush(WriteRqstPtr), and it indeed fixes the shutdown issue. Though I was under the impression that calling XLogSetAsyncXactLSN() in RecordTransactionAbort was a better approach, as it is similar to reporting the latest async abort. You may have a large backlog of records, like selects pruning a lot of pages and timing out, which the next commit will have to flush. Notifying the walwriter allows it to flush those records it can. Maybe for the context of a backport, patching ShutdownXLOG has the benefit of minimising the amount of changes and risks? I've updated the RecordTransactionAbort approach for now, with a small optimization. XactLastRecEnd may be 0 if nothing was written, and we can skip the unnecessary spinlocks in this case. Regards, Anthonin Bonnefoy
v3-0001-Fix-stuck-shutdown-due-to-unflushed-records.patch
Description: Binary data
