Re: Fix bugs not to discard statistics when changing stats_fetch_consistency - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Fix bugs not to discard statistics when changing stats_fetch_consistency
Date
Msg-id ZbtXYVvdgRsUVVwA@paquier.xyz
Whole thread Raw
In response to Fix bugs not to discard statistics when changing stats_fetch_consistency  (Shinya Kato <Shinya11.Kato@oss.nttdata.com>)
Responses Re: Fix bugs not to discard statistics when changing stats_fetch_consistency
List pgsql-hackers
On Thu, Jan 11, 2024 at 06:18:38PM +0900, Shinya Kato wrote:
> Hi, hackers

(Sorry for the delay, this thread was on my TODO list for some time.)

> There is below description in docs for stats_fetch_consistency.
> "Changing this parameter in a transaction discards the statistics snapshot."
>
> However, I wonder if changes stats_fetch_consistency in a transaction,
> statistics is not discarded in some cases.

Yep, you're right.  This is inconsistent with the documentation where
we need to clean up the cached data when changing this GUC.  I was
considering a few options regarding the location of the extra
pgstat_clear_snapshot(), but at the end I see the point in doing it in
a path even if it creates a duplicate with pgstat_build_snapshot()
when pgstat_fetch_consistency is using the snapshot mode.  A location
better than your patch is pgstat_snapshot_fixed(), though, so as new
stats kinds will be able to get the call.

I have been banging my head on my desk for a bit when thinking about a
way to test that in a predictible way, until I remembered that these
stats are only flushed at commit, so this requires at least two
sessions, with one of them having a transaction opened while
manipulating stats_fetch_consistency.  TAP would be one option, but
I'm not really tempted about spending more cycles with a
background_psql just for this case.  If I'm missing something, feel
free.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Anthonin Bonnefoy
Date:
Subject: Re: A performance issue with Memoize
Next
From: Richard Guo
Date:
Subject: Re: A performance issue with Memoize