Re: Flush SLRU counters in checkpointer process

From: Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>
To: daniel(at)yesql(dot)se
Cc: "Gregory Stark (as CFM)" <stark(dot)cfm(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Flush SLRU counters in checkpointer process
Date: 2023-07-19 06:36:34
Message-ID: CAO6_XqqqEHzKC5+qBZg+NASbGyVHHs=gFjRP46Hi8DMR4+VJRg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I think I've managed to reproduce the issue. The test I've added to check
slru flush was the one failing in the regression suite.

SELECT SUM(flushes) > :slru_flushes_before FROM pg_stat_slru;
?column?
----------
t

The origin seems to be a race condition on have_slrustats (
https://github.com/postgres/postgres/blob/c8e1ba736b2b9e8c98d37a5b77c4ed31baf94147/src/backend/utils/activity/pgstat_slru.c#L161-L162
).
I will try to get a new patch with improved test stability.

On Mon, Jul 3, 2023 at 3:18 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:

> > On 3 Mar 2023, at 09:06, Anthonin Bonnefoy <
> anthonin(dot)bonnefoy(at)datadoghq(dot)com> wrote:
> >
> > Here's the patch rebased with Andres' suggestions.
> > Happy to update it if there's any additionalj change required.
>
> This patch crashes 031_recovery_conflict with a SIGInvalid on Windows, can
> you
> please investigate and see what might be going on there? The test passed
> about
> 4 days ago on Windows so unless it's the CI being flaky it should be due
> to a
> recent change.
>
> If you don't have access to a Windows environment you can run your own
> instrumented builds in your Github account with the CI files in the
> postgres
> repo.
>
> --
> Daniel Gustafsson
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2023-07-19 06:37:21 Re: pg_recvlogical prints bogus error when interrupted
Previous Message Michael Paquier 2023-07-19 06:23:41 Re: Support to define custom wait events for extensions