Re: stats test intermittent failure

Поиск
Список
Период
Сортировка
От Masahiko Sawada
Тема Re: stats test intermittent failure
Дата
Msg-id CAD21AoC8sBen7FrEMoNnr4=KjY3-2piA7b==qSVX3t68qQzneA@mail.gmail.com
обсуждение исходный текст
Ответ на stats test intermittent failure  (Melanie Plageman <melanieplageman@gmail.com>)
Ответы Re: stats test intermittent failure  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Hi,

On Tue, Jul 11, 2023 at 3:35 AM Melanie Plageman
<melanieplageman@gmail.com> wrote:
>
> Hi,
>
> Jeff pointed out that one of the pg_stat_io tests has failed a few times
> over the past months (here on morepork [1] and more recently here on
> francolin [2]).
>
> Failing test diff for those who prefer not to scroll:
>
> +++ /home/bf/bf-build/francolin/HEAD/pgsql.build/testrun/recovery/027_stream_regress/data/results/stats.out
>    2023-07-07 18:48:25.976313231 +0000
> @@ -1415,7 +1415,7 @@
>         :io_sum_vac_strategy_after_reuses > :io_sum_vac_strategy_before_reuses;
>   ?column? | ?column?
>  ----------+----------
> - t        | t
> + t        | f
>
> My theory about the test failure is that, when there is enough demand
> for shared buffers, the flapping test fails because it expects buffer
> access strategy *reuses* and concurrent queries already flushed those
> buffers before they could be reused. Attached is a patch which I think
> will fix the test while keeping some code coverage. If we count
> evictions and reuses together, those should have increased.
>

Yeah, I've not reproduced this issue but it's possible. IIUC if we get
the buffer from the ring, we count an I/O as "reuse" even if the
buffer has already been flushed/replaced. However, if the buffer in
the ring is pinned by other backends, we end up evicting a buffer from
outside of the ring and adding it to the buffer, which is counted as
"eviction".

Regarding the patch, I have a comment:

 -- Test that reuse of strategy buffers and reads of blocks into these reused
--- buffers while VACUUMing are tracked in pg_stat_io.
+-- buffers while VACUUMing are tracked in pg_stat_io. If there is sufficient
+-- demand for shared buffers from concurrent queries, some blocks may be
+-- evicted from the strategy ring before they can be reused. In such cases
+-- this, the backend will evict a block from a shared buffer outside of the
+-- ring and add it to the ring. This is considered an eviction and not a reuse.

The new comment seems not to be accurate if my understanding is
correct. How about the following?

Test that reuse of strategy buffers and reads of blocks into these
reused buffers while VACUUMing are tracked in pg_stat_io. If there is
sufficient demand for shared buffers from concurrent queries, some
buffers may be pinned by other backends before they can be reused. In
such cases, the backend will evict a buffer from a shared buffer
outside of the ring and add it to the ring. This is considered an
eviction and not a reuse.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: John Naylor
Дата:
Сообщение: Re: Avoid undefined behavior with msvc compiler (src/include/port/pg_bitutils.h)
Следующее
От: Matthias van de Meent
Дата:
Сообщение: Re: New PostgreSQL Contributors