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

Xuneng Zhou <xunengzhou@gmail.com>

From: Xuneng Zhou <xunengzhou@gmail.com>

To: Michael Paquier <michael@paquier.xyz>

Cc: Noah Misch <noah@leadboat.com>, ryanzxg@gmail.com, pgsql-bugs@lists.postgresql.org, Euler Taveira <euler@eulerto.com>

Date: 2025-11-04T09:01:46Z

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 →

Add assertions checking for the startup process in WAL replay routines
- 2fc31079624e 19 (unreleased) landed
Add assertion check for WAL receiver state during stream-archive transition
- 65f4976189b6 19 (unreleased) landed
Add WalRcvGetState() to retrieve the state of a WAL receiver
- e0ca61e7c4d5 19 (unreleased) landed
Fix unconditional WAL receiver shutdown during stream-archive transition
- 25b484080f14 13.23 landed
- a1b8b3b2e385 14.20 landed
- da5ea6c70bc4 15.15 landed
- 9b61096074af 16.11 landed
- e7340b484c34 17.7 landed
- a14201073965 18.1 landed
- 17b2d5ec759c 19 (unreleased) landed
Add test tracking WAL receiver shutdown for primary_conninfo updates
- c9e38a569c5f 19 (unreleased) landed
Reset InstallXLogFileSegmentActive after walreceiver self-initiated exit.
- 3635a0a35aaf 14.18 cited
- b4f584f9d2a1 16.0 cited
Replace durable_rename_excl() by durable_rename(), take two
- 1f95181b44c8 14.16 cited
Split xlog.c into xlog.c and xlogrecovery.c.
- 70e81861fadd 15.0 cited

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