Re: BUG #17804: Assertion failed in pg_stat after fetching from pg_stat_database and switching cache->snapshot - Mailing list pgsql-bugs

From Alexander Lakhin
Subject Re: BUG #17804: Assertion failed in pg_stat after fetching from pg_stat_database and switching cache->snapshot
Date
Msg-id 1836967a-9f78-aed8-1ff1-3351c504e8f0@gmail.com
Whole thread Raw
In response to Re: BUG #17804: Assertion failed in pg_stat after fetching from pg_stat_database and swithing cache->snapshot  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: BUG #17804: Assertion failed in pg_stat after fetching from pg_stat_database and switching cache->snapshot  (Alexander Lakhin <exclusion@gmail.com>)
List pgsql-bugs
Hello Kyotaro-san,
24.02.2023 10:08, Kyotaro Horiguchi wrote:
> Thanks for the report!  We didn't consider the case that variable is
> changed in-transaction.
>
>
> What are your thoughts on this?
What if we implement assign_pgstat_fetch_consistency() and execute
pgstat_clear_snapshot() in it when the mode switch happens (to avoid
possible inconsistency between the GUC and the current pgstat state)?
If snapshots in different modes contain different data sets, will such
behaviour be unexpected for a user?
For example, if a user performs:
SET LOCAL stats_fetch_consistency = snapshot;
{some-actions-1}
SET LOCAL stats_fetch_consistency = none;
{some-actions-2}
SET LOCAL stats_fetch_consistency = snapshot;
{some-actions-3}
Should she expect that some-actions-1, some-actions-2 will be
reflected in the snapshot at the end?

Best regards,
Alexander



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17806: PostgreSQL 13.10 returns "CREATE DATABASE cannot be executed within a pipeline"
Next
From: Tom Lane
Date:
Subject: Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values