Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)

From: Melanie Plageman <melanieplageman(at)gmail(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, andres(at)anarazel(dot)de, vignesh21(at)gmail(dot)com, pryzby(at)telsasoft(dot)com, lukas(at)fittl(dot)com, alvherre(at)alvh(dot)no-ip(dot)org, magnus(at)hagander(dot)net, pgsql-hackers(at)postgresql(dot)org, thomas(dot)munro(at)gmail(dot)com, m(dot)sakrejda(at)gmail(dot)com
Subject: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
Date: 2023-03-06 15:09:24
Message-ID: CAAKRu_ZRKp-zDCSVk9p8XE=ZKTn3WiJD6Mt=n=eSPQ7Kg-=HRw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 6, 2023 at 1:48 AM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
> At Mon, 06 Mar 2023 15:24:25 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote in
> > In any case, I think we need to avoid such concurrent autovacuum/analyze.
>
> If it is correct, I believe the attached fix works.

Thanks for investigating this!

Yes, this fix looks correct and makes sense to me.

On Mon, Mar 6, 2023 at 1:24 AM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
> At Sat, 04 Mar 2023 18:21:09 -0500, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in
> > Andres Freund <andres(at)anarazel(dot)de> writes:
> > > Just pushed the actual pg_stat_io view, the splitting of the tablespace test,
> > > and the pg_stat_io tests.
> >
> > One of the test cases is flapping a bit:
> >
> > diff -U3 /home/pg/build-farm-15/buildroot/HEAD/pgsql.build/src/test/regress/expected/stats.out /home/pg/build-farm-15/buildroot/HEAD/pgsql.build/src/test/regress/results/stats.out
> > --- /home/pg/build-farm-15/buildroot/HEAD/pgsql.build/src/test/regress/expected/stats.out 2023-03-04 21:30:05.891579466 +0100
> > +++ /home/pg/build-farm-15/buildroot/HEAD/pgsql.build/src/test/regress/results/stats.out 2023-03-04 21:34:26.745552661 +0100
> > @@ -1201,7 +1201,7 @@
> > SELECT :io_sum_shared_after_reads > :io_sum_shared_before_reads;
> > ?column?
> > ----------
> > - t
> > + f
> > (1 row)
> >
> > DROP TABLE test_io_shared;
> >
> > There are two instances of this today [1][2], and I've seen it before
> > but failed to note down where.
>
> The concurrent autoanalyze below is logged as performing at least one
> page read from the table. It is unclear, however, how that analyze
> operation resulted in 19 hits and 2 reads on the (I think) single-page
> relation.

Yes, it is a single page.
I think there could be a few different reasons by it is 2 misses/2
dirtied, but the one that seems most likely is that I/O of other
relations done during this autovac/analyze of this relation is counted
in the same global variables (like catalog tables).

- Melanie

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-03-06 15:12:06 Re: wrong results due to qual pushdown
Previous Message Matthias van de Meent 2023-03-06 15:08:28 Re: Add pg_walinspect function with block info columns