On Mon, Mar 6, 2023 at 1:48 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
>
> At Mon, 06 Mar 2023 15:24:25 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.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.ntt@gmail.com> wrote:
>
> At Sat, 04 Mar 2023 18:21:09 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in
> > Andres Freund <andres@anarazel.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