On Fri, Nov 19, 2021 at 7:09 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, Nov 19, 2021 at 3:00 PM Greg Nancarrow <gregn4422@gmail.com> wrote:
> >
> > On Fri, Nov 19, 2021 at 8:15 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > > Yeah in such a case last_error_time can be shown as a time before
> > > first_error_time but I don't think that will be a big problem, the
> > > next message will fix it. I don't see what we can do about it and the
> > > same is true for other cases like pg_stat_archiver where the success
> > > and failure times can be out of order. If we want we can remove one of
> > > those times but I don't think this happens frequently enough to be
> > > considered a problem. Anyway, these stats are not considered to be
> > > updated with the most latest info.
> > >
> >
> > Couldn't the code block in pgstat_recv_subworker_error() that
> > increments error_count just compare the new msg timestamp against the
> > existing first_error_time and last_error_time and, based on the
> > result, update those if required?
> >
>
> I don't see any problem with that but let's see what Sawada-San has to
> say about this?
IMO not sure we should do that. Since the stats collector will not
likely to receive the same error report frequently in practice (5 sec
interval by default), perhaps this problem will unlikely to happen.
Even if the same messages are reported frequently enough to cause this
problem, the next message will also be reported soon, fixing it soon,
as Amit mentioned. Also, IIUC once we have the shared memory based
stats collector, we won’t need to worry about this problem. Given that
this kind of problem potentially exists also in other stats views that
have timestamp values, I’m not sure it's worth dealing with this
problem only in pg_stat_subscription_workers view.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
