Re: Resetting spilled txn statistics in pg_stat_replication

On Tue, Oct 13, 2020 at 10:33 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Tue, Oct 13, 2020 at 10:21 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> > > On Tue, Oct 13, 2020 at 9:25 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > >> It's not very clear what spill_count actually counts (and the
> > >> documentation sure does nothing to clarify that), but if it has anything
> > >> to do with WAL volume, the explanation might be that florican is 32-bit.
> > >> All the animals that have passed that test so far are 64-bit.
> >
> > prairiedog just failed in not-quite-the-same way, which reinforces the
> > idea that this test is dependent on MAXALIGN, which determines physical
> > tuple size. (I just checked the buildfarm, and the four active members
> > that report MAXALIGN 4 during configure are florican, lapwing, locust,
> > and prairiedog. Not sure about the MSVC critters though.) The
> > spill_count number is different though, so it seems that that may not
> > be the whole story.
> >
>
> It is possible that MAXALIGN stuff is playing a role here and or the
> background transaction stuff. I think if we go with the idea of
> testing spill_txns and spill_count being positive then the results
> will be stable. I'll write a patch for that.
>

Please find the attached patch for the same. Additionally, I have
skipped empty xacts during decoding as background autovacuum
transactions can impact that count as well. I have done some minimal
testing with this. I'll do some more.

--
With Regards,
Amit Kapila.