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

From osumi.takamichi@fujitsu.com
Subject RE: Design of pg_stat_subscription_workers vs pgstats
Date
Msg-id TYCPR01MB837314CD88ECC298874D5CCBED3C9@TYCPR01MB8373.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 Tuesday, February 22, 2022 11:47 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> On Tue, Feb 22, 2022 at 9:22 PM osumi.takamichi@fujitsu.com
> <osumi.takamichi@fujitsu.com> wrote:
> > (4) doc/src/sgml/monitoring.sgml
> >
> >       <row>
> >        <entry role="catalog_table_entry"><para
> role="column_definition">
> > -       <structfield>last_error_time</structfield> <type>timestamp with
> time zone</type>
> > +       <structfield>sync_error_count</structfield> <type>uint8</type>
> >        </para>
> >        <para>
> > -       Last time at which this error occurred
> > +       Number of times the error occurred during the initial data
> > + copy
> >        </para></entry>
> >
> > I supposed it might be better to use "initial data sync"
> > or "initial data synchronization", rather than "initial data copy".
> 
> "Initial data synchronization" sounds like the whole table synchronization
> process including COPY and applying changes to catch up. But
> sync_error_count is incremented only during COPY so I used "initial data copy".
> What do you think?
Okay. Please keep it as is.


Best Regards,
    Takamichi Osumi


pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: pgcrypto: Remove internal padding implementation
Next
From: Andres Freund
Date:
Subject: Re: Race condition in InvalidateObsoleteReplicationSlots()