Re: Question about StartLogicalReplication() error path

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Question about StartLogicalReplication() error path
Дата
Msg-id 20022e5d31d1a38b6bbf1b4e4f03eb94507342b3.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: Question about StartLogicalReplication() error path  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Question about StartLogicalReplication() error path  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Sat, 2021-06-12 at 16:17 +0530, Amit Kapila wrote:
> AFAIU, currently, in such a case, the subscriber (client) won't
> advance the flush location (confirmed_flush_lsn). So, we won't lose
> any data.

I think you are talking about the official Logical Replication
specifically, rather than an arbitrary client that's using the logical
replication protocol based on the protocol docs.


It seems that there's not much agreement in a behavior change here. I
suggest one or more of the following:

 1. change the logical rep protocol docs to match the current behavior
    a. also briefly explain in the docs why it's different from
physical replication (which does always start at the provided LSN as
far as I can tell)

 2. Change the comment to add something like "Starting at a different
LSN than requested might not catch certain kinds of client errors.
Clients should be careful to check confirmed_flush_lsn if starting at
the requested LSN is required."

 3. upgrade DEBUG1 message to a WARNING

Can I get agreement on any of the above suggestions?

Regards,
    Jeff Davis





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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: recent failures on lorikeet
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Race condition in recovery?