Re: Fix bugs not to discard statistics when changing stats_fetch_consistency
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Shinya Kato <Shinya11.Kato@oss.nttdata.com>
Cc: pgsql-hackers@postgresql.org
Date: 2024-02-01T08:33:37Z
Lists: 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
Commits
-
Fix stats_fetch_consistency with stats for fixed-numbered objects
- 171d21f50c3e 15.6 landed
- 781bc121de89 16.2 landed
- 235c09efbb30 17.0 landed