Re: Standby server with cascade logical replication could not be properly stopped under load
От | Ajin Cherian |
---|---|
Тема | Re: Standby server with cascade logical replication could not be properly stopped under load |
Дата | |
Msg-id | CAFPTHDZu40jysBrqmSYHpumoEDFDs8JoZL3hsN80rFt394Fttw@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 |
On Thu, May 29, 2025 at 5:02 PM Michael Paquier <michael@paquier.xyz> wrote:
nd master versions.
Yeah, I think that this is a sensible move. Documenting the reason
why GetXLogReplayRecPtr() is called is important, but the comment you
are suggesting could be better, IMO, say:
"For cascading logical WAL senders, we use the replay LSN rather than
the flush LSN, as decoding would only happen with records already
replayed. This distinction is important especially during the
shutdown sequence, as cascading logical WAL senders can only catch up
with records that have been already replayed, not flushed."
That feels that I'm repeating myself a bit twice if formulated this
way. If you have a better suggestion, feel free..
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."
"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."
regards,
Ajin Cherian
Fujitsu Australia
В списке pgsql-bugs по дате отправления: