Re: Standby server with cascade logical replication could not be properly stopped under load - Mailing list pgsql-bugs

From G. Sl
Subject Re: Standby server with cascade logical replication could not be properly stopped under load
Date
Msg-id CABPnX-ZrhHwvPr2LgjWF0S1kjgSELXkdnfBK-su2ue562DjyHA@mail.gmail.com
Whole thread Raw
In response to Re: Standby server with cascade logical replication could not be properly stopped under load  (shveta malik <shveta.malik@gmail.com>)
Responses Re: Standby server with cascade logical replication could not be properly stopped under load
List pgsql-bugs
Hi Michael ! 
I've found the same behaviour in the 15.12 version. Any chances for backpatch for this version ?
-- 
Best regards
Gennadiy S.
On Fri, 26 Dec 2025 at 16:11, Michael Paquier <michael@paquier.xyz> wrote:
On Fri, May 30, 2025 at 08:32:05AM +0900, Michael Paquier wrote:
> On Thu, May 29, 2025 at 08:28:01PM +1000, Ajin Cherian wrote:
>> I think this new fix is much better and cleaner. A suggestion for the
>> comment:
>> "For cascading logical WAL senders, we use the replay LSN instead of the
>> flush LSN, since logical decoding on a standby only processes WAL that has
>> been replayed. This distinction becomes particularly important during
>> shutdown, as new WAL is no longer replayed and the last replayed LSN marks
>> the furthest point up to which decoding can proceed."
>
> Yes, that sounds better than my previous suggestion.  Thanks.

I have reused that wording, did more tests on v16 and v17, reproducing
both the problems reported and that the change fixes the shutdown of
the physical standby, then applied the change down to v16.

Thanks all.
--
Michael

pgsql-bugs by date:

Previous
From: "ZhangChi"
Date:
Subject: Re: BUG #19356: Unexpected result of prepared UPDATE with force_generic_plan
Next
From: PG Bug reporting form
Date:
Subject: BUG #19363: PostgreSQL shared memory exhaustion during query execution involving views and parallel workers