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."

regards,
Ajin Cherian
Fujitsu Australia

В списке pgsql-bugs по дате отправления: