Re: Resetting spilled txn statistics in pg_stat_replication

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Resetting spilled txn statistics in pg_stat_replication
Дата
Msg-id CAA4eK1KdMmvmyDBV-DqP7u3Qu+rjR3xf9kCOVPo70Ds27riG_w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Resetting spilled txn statistics in pg_stat_replication  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Ответы Re: Resetting spilled txn statistics in pg_stat_replication  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Список pgsql-hackers
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.

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.

> > I think after we are done with this the next
> > step would be to finish the streaming stats work [1]. We probably need
> > to review and add the test case in that patch. If nobody else shows up
> > I will pick it up and complete it.
>
> +1
> I can review that patch.
>

Thanks!

--
With Regards,
Amit Kapila.



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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Transactions involving multiple postgres foreign servers, take 2
Следующее
От: vignesh C
Дата:
Сообщение: Re: Parallel copy