Re: Replication slot stats misgivings

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Subject: Re: Replication slot stats misgivings
Date: 2021-05-12 10:32:10
Message-ID: CAD21AoBJx9Ddn7ux-A3hZwxHo4khEG5=dEez1fxf7mFcAKy-sw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 12, 2021 at 1:19 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Wed, May 12, 2021 at 9:08 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Wed, May 12, 2021 at 7:53 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > >
> > > On Wed, May 12, 2021 at 4:00 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > > >
> > > > Ugh, since by commit 592f00f8de we send slot stats every after
> > > > spil/stream it’s possible that we report slot stats that have non-zero
> > > > counters for spill_bytes/txns and zeroes for total_bytes/txns. It
> > > > seems to me it’s legitimate that the slot stats view shows non-zero
> > > > values for spill_bytes/txns and zero values for total_bytes/txns
> > > > during decoding a large transaction. So I think we can fix the test
> > > > script so that it checks only spill_bytes/txns when checking spilled
> > > > transactions.
> > > >
> > >
> > > Your analysis and fix look correct to me.
> > >
> >
> > I think the part of the test that tests the stats after resetting it
> > might give different results. This can happen because in the previous
> > test we spill multiple times (spill_count is 12 in my testing) and it
> > is possible that some of the spill stats messages is received by stats
> > collector after the reset message. If this theory is correct then it
> > better that we remove the test for reset stats and the test after it
> > "decode and check stats again.". This is not directly related to your
> > patch or buildfarm failure but I guess this can happen and we might
> > see such a failure in future.

Good point. I agree to remove this test.

>
> I agree with your analysis to remove that test. Attached patch has the
> changes for the same.

Thank you for the patch. The patch looks good to me. I also agree that
removing the test doesn't reduce the test coverage.

Regards,

--
Masahiko Sawada
EDB: https://www.enterprisedb.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Astapov 2021-05-12 10:41:20 Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?
Previous Message Pavel Stehule 2021-05-12 10:25:00 Re: proposal - psql - use pager for \watch command