Horton

Re: Shutdown indefinitely stuck due to unflushed FPI_FOR_HINT record

Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>

View thread View on postgr.es
From: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2026-03-02T10:38:06Z
Lists: pgsql-hackers

Attachments

On Thu, Feb 26, 2026 at 5:20 PM Fujii Masao <masao.fujii@gmail.com> 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

Commits

  1. Fix WAL flush LSN used by logical walsender during shutdown

  2. Use GetXLogInsertEndRecPtr in gistGetFakeLSN

  3. Fix publisher shutdown hang caused by logical walsender busy loop.