Re: Skipping logical replication transactions on subscriber side - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Skipping logical replication transactions on subscriber side
Date
Msg-id CAD21AoB9Tq__zCcB_1_G9GoK3P_Pxp7-bQ6qQmSBLZBx_Og==g@mail.gmail.com
Whole thread Raw
In response to Re: Skipping logical replication transactions on subscriber side  (Alexey Lesovsky <lesovsky@gmail.com>)
Responses Re: Skipping logical replication transactions on subscriber side  (Amit Kapila <amit.kapila16@gmail.com>)
Re: Skipping logical replication transactions on subscriber side  (Alexey Lesovsky <lesovsky@gmail.com>)
List pgsql-hackers
On Mon, Jul 5, 2021 at 7:33 PM Alexey Lesovsky <lesovsky@gmail.com> wrote:
>
> Hi,
> Have a few notes about pg_stat_logical_replication_error from the DBA point of view (which will use this view in the
future).

Thank you for the comments!

> 1. As I understand it, this view might contain many errors related to different subscriptions. It is better to name
"pg_stat_logical_replication_errors"using the plural form (like this done for stat views for tables, indexes,
functions).

Agreed.

> Also, I'd like to suggest thinking twice about the view name (and function used in view DDL) -
"pg_stat_logical_replication_error"contains very common "logical replication" words, but the view contains errors
relatedto subscriptions only. In the future there could be other kinds of errors related to logical replication, but
notrelated to subscriptions - what will you do? 

Is pg_stat_subscription_errors or
pg_stat_logical_replication_apply_errors better?

> 2. Add a field with database name or id - it helps to quickly understand to which database the subscription belongs.

Agreed.

> 3. Add a counter field with total number of errors - it helps to calculate errors rates and aggregations (sum), and
don'tlose information about errors between view checks. 

Do you mean to increment the error count if the error (command, xid,
and relid) is the same as the previous one? or to have the total
number of errors per subscription? And what can we infer from the
error rates and aggregations?

> 4. Add text of last error (if it will not be too expensive).

Agreed.

> 5. Rename the "action" field to "command", as I know this is right from terminology point of view.

Okay.

Regards,

--
Masahiko Sawada
EDB:  https://www.enterprisedb.com/



pgsql-hackers by date:

Previous
From: Boris Kolpackov
Date:
Subject: Re: Pipeline mode and PQpipelineSync()
Next
From: Dipesh Pandit
Date:
Subject: Re: .ready and .done files considered harmful