Re: Resetting spilled txn statistics in pg_stat_replication

Поиск
Список
Период
Сортировка
От Masahiko Sawada
Тема Re: Resetting spilled txn statistics in pg_stat_replication
Дата
Msg-id CA+fd4k5Yf3uJH4TrWY544HgAS7sSZNcHcAZMA3yQGRHB2UwToQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Resetting spilled txn statistics in pg_stat_replication  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Resetting spilled txn statistics in pg_stat_replication  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Thu, 8 Oct 2020 at 14:10, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Thu, Oct 8, 2020 at 7:46 AM Masahiko Sawada
> <masahiko.sawada@2ndquadrant.com> wrote:
> >
> > On Wed, 7 Oct 2020 at 17:52, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > On Wed, Oct 7, 2020 at 11:24 AM Masahiko Sawada
> > > <masahiko.sawada@2ndquadrant.com> wrote:
> > > >
> > > > On Tue, 6 Oct 2020 at 17:56, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > > > >
> > > > > On Tue, Oct 6, 2020 at 9:34 AM Masahiko Sawada
> > > > > <masahiko.sawada@2ndquadrant.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: dynamic result sets support in extended query protocol
Следующее
От: Keisuke Kuroda
Дата:
Сообщение: Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables