Re: Failed transaction statistics to measure the logical replication progress - Mailing list pgsql-hackers

From Greg Nancarrow
Subject Re: Failed transaction statistics to measure the logical replication progress
Date
Msg-id CAJcOf-fMzh_EjUb=ik2u1USeBnN_9pXjcCNGeEdzpmb6GNJE4A@mail.gmail.com
Whole thread Raw
In response to Re: Failed transaction statistics to measure the logical replication progress  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Failed transaction statistics to measure the logical replication progress
List 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 by date:

Previous
From: Amul Sul
Date:
Subject: TAP test to cover "EndOfLogTLI != replayTLI" case
Next
From: vignesh C
Date:
Subject: Re: row filtering for logical replication