RE: Design of pg_stat_subscription_workers vs pgstats - Mailing list pgsql-hackers

From tanghy.fnst@fujitsu.com
Subject RE: Design of pg_stat_subscription_workers vs pgstats
Date
Msg-id TYCPR01MB612840D018FEBD38268CC83BFB3C9@TYCPR01MB6128.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Design of pg_stat_subscription_workers vs pgstats  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Tue, Feb 22, 2022 1:45 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> 
> I've attached a patch that changes pg_stat_subscription_workers view.
> It removes non-cumulative values such as error details such as
> error-XID and the error message from the view, and consequently the
> view now has only cumulative statistics counters: apply_error_count
> and sync_error_count. Since the new view name is under discussion I
> temporarily chose pg_stat_subscription_activity.
> 

Thanks for your patch.

Few comments:

1.
+       <structfield>apply_error_count</structfield> <type>uint8</type>
...
+       <structfield>sync_error_count</structfield> <type>uint8</type>

It seems that Postgres has no data type named uint8, should we change it to
bigint?

2.
+# Wait for the table sync error to be reported.
+$node_subscriber->poll_query_until(
+    'postgres',
+    qq[
+SELECT apply_error_count = 0 AND sync_error_count > 0
+FROM pg_stat_subscription_activity
+WHERE subname = 'tap_sub'
+]) or die "Timed out while waiting for table sync error";

We want to check table sync error here, but do we need to check
"apply_error_count = 0"? I am not sure if it is possible that the apply worker has
an unexpected error, which would cause this test to fail.

Regards,
Tang

pgsql-hackers by date:

Previous
From: Ajin Cherian
Date:
Subject: Re: logical replication empty transactions
Next
From: Peter Smith
Date:
Subject: Re: Design of pg_stat_subscription_workers vs pgstats