Horton

Re: BUG #19093: Behavioral change in walreceiver termination between PostgreSQL 14.17 and 14.18

xingguo <ryanzxg@gmail.com>

View thread
From: xingguo <ryanzxg@gmail.com>
To: Xuneng Zhou <xunengzhou@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Noah Misch <noah@leadboat.com>, pgsql-bugs@lists.postgresql.org, Euler Taveira <euler@eulerto.com>
Date: 2025-11-04T09:31:24Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add assertions checking for the startup process in WAL replay routines

  2. Add assertion check for WAL receiver state during stream-archive transition

  3. Add WalRcvGetState() to retrieve the state of a WAL receiver

  4. Fix unconditional WAL receiver shutdown during stream-archive transition

  5. Add test tracking WAL receiver shutdown for primary_conninfo updates

  6. Reset InstallXLogFileSegmentActive after walreceiver self-initiated exit.

  7. Replace durable_rename_excl() by durable_rename(), take two

  8. Split xlog.c into xlog.c and xlogrecovery.c.

Hi Xuneng and Michael,

Thank you so much for the quick response and for fixing the issue. I saw
that the commit has already been merged into master.

I’d like to ask whether this fix will be included in the patch release for
version 14 - specifically 14.20. I noticed the commit mentions
Backpatch-through: 13, and I want to confirm whether that means the fix
will be backpatched to version 13 and all subsequent supported versions.

Thanks again!

Best regards,
Xingguo

Xuneng Zhou <xunengzhou@gmail.com>于2025年11月4日 周二17:01写道：

> Hi, Michael!
>
> On Tue, Nov 4, 2025 at 12:52 PM Michael Paquier <michael@paquier.xyz>
> wrote:
> >
> > On Sat, Nov 01, 2025 at 08:44:55AM +0800, Xuneng Zhou wrote:
> > > On Sat, Nov 1, 2025 at 8:17 AM Michael Paquier <michael@paquier.xyz>
> wrote:
> > >> Thanks, that looks sensible.  I'll revisit what you have at the
> > >> beginning of next week (local Tuesday) with a backpatch down to v13 in
> > >> mind.  If others have comments and/or objections, please feel free to
> > >> chime in.
> > >
> > > It's an oversight. Thanks for catching it.
> >
> > Phew, done.
>
> Thanks for pushing the patches!
>
> > While looking at the whole thing, I was wondering if we
> > should strengthen a little bit what's expected of the context for some
> > of the callers of the WAL routines, like XLogShutdownWalRcv(), and
> > finished with the bonus patch attached.  What do you think?
>
> The change LGTM — it ensures that the walreceiver’s lifecycle is
> orchestrated entirely by the startup process.
>
> Best,
> Xuneng
>