Re: Resetting spilled txn statistics in pg_stat_replication

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.
In either way, since the stats correspond to the logical decoding
using the same slot with the same parameter value the user can use
them directly.

Regards,

--
Masahiko Sawada http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services