Re: Resetting spilled txn statistics in pg_stat_replication

From: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Resetting spilled txn statistics in pg_stat_replication
Date: 2020-10-08 08:24:52
Message-ID: CA+fd4k5Yf3uJH4TrWY544HgAS7sSZNcHcAZMA3yQGRHB2UwToQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 8 Oct 2020 at 14:10, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Thu, Oct 8, 2020 at 7:46 AM Masahiko Sawada
> <masahiko(dot)sawada(at)2ndquadrant(dot)com> wrote:
> >
> > On Wed, 7 Oct 2020 at 17:52, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > >
> > > On Wed, Oct 7, 2020 at 11:24 AM Masahiko Sawada
> > > <masahiko(dot)sawada(at)2ndquadrant(dot)com> wrote:
> > > >
> > > > On Tue, 6 Oct 2020 at 17:56, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > > > >
> > > > > On Tue, Oct 6, 2020 at 9:34 AM Masahiko Sawada
> > > > > <masahiko(dot)sawada(at)2ndquadrant(dot)com> wrote:
> > > > > >
> > > > > > Looking at pgstat_reset_replslot_counter() in the v8 patch, even if we
> > > > > > pass a physical slot name to pg_stat_reset_replication_slot() a
> > > > > > PgStat_MsgResetreplslotcounter is sent to the stats collector. I’m
> > > > > > okay with not raising an error but maybe we can have it not to send
> > > > > > the message in that case.
> > > > > >
> > > > >
> > > > > makes sense, so changed accordingly.
> > > > >
> > > >
> > > > Thank you for updating the patch!
> > > >
> > >
> > > Thanks, I will push the first one tomorrow unless I see more comments
> > > and test-case one later.
> >
> > I thought we could have a test case for the reset function, what do you think?
> >
>
> We can write if we want but there are few things we need to do for
> that like maybe a new function like wait_for_spill_stats which will
> check if the counters have become zero. Then probably call a reset
> function, call a new wait function, and then again check stats to
> ensure they are reset to 0.

Yes.

> We can't write any advanced test which means reset the existing stats
> perform some tests and again check stats because *slot_get_changes()
> function can start from the previous WAL for which we have covered the
> stats. We might write that if we can somehow track the WAL positions
> from the previous test. I am not sure if we want to go there.

Can we use pg_logical_slot_peek_changes() instead to decode the same
transactions multiple times?

Regards,

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Keisuke Kuroda 2020-10-08 08:35:45 Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
Previous Message Tatsuo Ishii 2020-10-08 08:23:54 Re: dynamic result sets support in extended query protocol