Horton

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

Euler Taveira <euler@eulerto.com>

View thread
From: "Euler Taveira" <euler@eulerto.com>
To: xingguo <ryanzxg@gmail.com>, "Xuneng Zhou" <xunengzhou@gmail.com>, "Noah Misch" <noah@leadboat.com>
Cc: pgsql-bugs@lists.postgresql.org
Date: 2025-10-24T15:11:22Z
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.

On Fri, Oct 24, 2025, at 5:33 AM, xingguo wrote:
> I’d like to ask about the fix plan for this issue. Will there be any 
> releases after 14.19, and if so, is this issue expected to be fixed in 
> the 14 branch? Also, will it be addressed in version 16?
>

I didn't have an opinion about this change behavior. Maybe Noah can comment on
it. Until we have an agreement that this is a regression, there is no fix plan.
Regarding v14, it will be supported for another year [1]. If the regression was
applied to old stable branches, it should be fixed as well. Sometimes, we need
a totally different patch for back branches. There are cases that the
regression is not triggered in old branches and the committer decides it is not
worth to apply it. Sometimes the fix is invasive (for example, require other
commits to be backported) and the bug is rare that we leave it alone.

In summary, stable branches usually don't change the behavior (unless we
consider the behavior totally broken).


[1] https://www.postgresql.org/support/versioning/


-- 
Euler Taveira
EDB   https://www.enterprisedb.com/