Re: Fix bugs not to discard statistics when changing stats_fetch_consistency

From: Shinya Kato <Shinya11(dot)Kato(at)oss(dot)nttdata(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fix bugs not to discard statistics when changing stats_fetch_consistency
Date: 2024-02-01 12:22:48
Message-ID: fc1cce6f1c4f3f1f9bb60c29302ae140@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2024-02-01 17:33, Michael Paquier wrote:
> 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.

Thank you for the review and pushing!
I think it is better and more concise than my implementation.

--
Regards,
Shinya Kato
NTT DATA GROUP CORPORATION

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2024-02-01 12:33:04 Re: Possibility to disable `ALTER SYSTEM`
Previous Message shveta malik 2024-02-01 12:16:11 Re: Synchronizing slots from primary to standby