Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
От | Melanie Plageman |
---|---|
Тема | Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?) |
Дата | |
Msg-id | CAAKRu_ZRKp-zDCSVk9p8XE=ZKTn3WiJD6Mt=n=eSPQ7Kg-=HRw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?) (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: