Re: Failed transaction statistics to measure the logical replication progress

Поиск
Список
Период
Сортировка
От Greg Nancarrow
Тема Re: Failed transaction statistics to measure the logical replication progress
Дата
Msg-id CAJcOf-fMzh_EjUb=ik2u1USeBnN_9pXjcCNGeEdzpmb6GNJE4A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Failed transaction statistics to measure the logical replication progress  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: Failed transaction statistics to measure the logical replication progress  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
On Sat, Nov 20, 2021 at 1:11 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> I'm concerned that these new names will introduce confusion; if we
> have last_error_relid, last_error_command, last_error_message,
> last_error_time, and last_error_xid, I think users might think that
> first_error_time is the timestamp at which an error occurred for the
> first time in the subscription worker.

You mean you think users might think "first_error_time" is the
timestamp at which the last_error first occurred (rather than the
timestamp of the first of any type of error that occurred) on that
worker?

> ... Also, I'm not sure
> last_error_count is not clear to me (it looks like showing something
> count but the only "last" one?).

It's the number of times that the last_error has occurred.
Unless it's some kind of transient error, that might get resolved
without intervention, logical replication will get stuck in a loop
retrying and the last error will occur again and again, hence the
count of how many times that has happened.
Maybe there's not much benefit in counting different errors prior to
the last error?


Regards,
Greg Nancarrow
Fujitsu Australia



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

Предыдущее
От: Amul Sul
Дата:
Сообщение: TAP test to cover "EndOfLogTLI != replayTLI" case
Следующее
От: vignesh C
Дата:
Сообщение: Re: row filtering for logical replication