Re: Standby server with cascade logical replication could not be properly stopped under load
| От | G. Sl |
|---|---|
| Тема | Re: Standby server with cascade logical replication could not be properly stopped under load |
| Дата | |
| Msg-id | CABPnX-ZrhHwvPr2LgjWF0S1kjgSELXkdnfBK-su2ue562DjyHA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Standby server with cascade logical replication could not be properly stopped under load (shveta malik <shveta.malik@gmail.com>) |
| Ответы |
Re: Standby server with cascade logical replication could not be properly stopped under load
|
| Список | pgsql-bugs |
Hi Michael !
I've found the same behaviour in the 15.12 version. Any chances for backpatch for this version ?
--
Best regardsI've found the same behaviour in the 15.12 version. Any chances for backpatch for this version ?
--
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 по дате отправления: