Re: Resetting spilled txn statistics in pg_stat_replication

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Resetting spilled txn statistics in pg_stat_replication
Date: 2020-06-17 11:14:07
Message-ID: CAA4eK1LVOOfWhz4mP3PbswMfr6HYV3PMpLtt-1N8UW8Ah+mgSQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 17, 2020 at 1:34 PM Masahiko Sawada
<masahiko(dot)sawada(at)2ndquadrant(dot)com> wrote:
>
> On Sat, 13 Jun 2020 at 14:23, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Fri, Jun 12, 2020 at 6:11 PM Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> > >
> > > On Fri, Jun 12, 2020 at 10:23 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > >>
> > >
> > >
> > > The problem with "lifetime of a process" is that it's not predictable. A replication process might "bounce" for any reason, and it is normally not a problem. But if you suddenly lose your stats when you do that, it starts to matter a lot more. Especially when you don't know if it bounced. (Sure you can look at the backend_start time, but that adds a whole different sets of complexitites).
> > >
> >
> > It is not clear to me what is a good way to display the stats for a
> > process that has exited or bounced due to whatever reason. OTOH, if
> > we just display per-slot stats, it is difficult to imagine how the
> > user can make any sense out of it or in other words how such stats can
> > be useful to users.
>
> If we have the reset function, the user can reset before doing logical
> decoding so that the user can use the stats directly. Or I think we
> can automatically reset the stats when logical decoding is performed
> with different logical_decoding_work_mem value than the previous one.
>

I had written above in the context of persisting these stats. I mean
to say if the process has bounced or server has restarted then the
previous stats might not make much sense because we were planning to
use pid [1], so the stats from process that has exited might not make
much sense or do you think that is okay? If we don't want to persist
and the lifetime of these stats is till the process is alive then we
are fine.

[1] - https://www.postgresql.org/message-id/CA%2Bfd4k5nqeFdhpnCULpTh9TR%2B15rHZSbz0SDC6sZhr_v99SeKA%40mail.gmail.com

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Laurenz Albe 2020-06-17 11:39:30 Re: pgstattuple: Have pgstattuple_approx accept TOAST tables
Previous Message Fujii Masao 2020-06-17 11:13:01 Re: Review for GetWALAvailability()