Re: BUG #17804: Assertion failed in pg_stat after fetching from pg_stat_database and swithing cache->snapshot

At Wed, 22 Feb 2023 06:00:01 +0000, PG Bug reporting form <noreply@postgresql.org> wrote in 
> The following transaction:
> BEGIN;
> SET LOCAL stats_fetch_consistency = cache;
> SELECT * FROM pg_stat_database;
> SET LOCAL stats_fetch_consistency = snapshot;
> SELECT pg_stat_get_function_calls(0);
> 
> raises an assertion failure with the following stack:
> Core was generated by `postgres: law regression [local] SELECT              
>                         '.
> Program terminated with signal SIGABRT, Aborted.

Thanks for the report!  We didn't consider the case that variable is
changed in-transaction.

Perhaps we should reject changes to fetch consistency once we the
snapshot hash is created.  I can think of two ways to do this. One
approach is to perform that check at GUC-level. However, this would
result in an ERROR meassage that isn't very informative. Addition to
that, it seems like aborting the transaction would be too severe a
punishment for this operation.

ERROR:  invalid value for parameter "stats_fetch_consistency": "cache"
DETAIL:  pgstat_fetch_consistency cannot be changed in this context.
ERROR:  current transaction is aborted, commands ignored until end of transactio

The attached is an alternative solution. If pgstat_fetch_consistency
is different from the existing snapshot, pgstat_fetch_entry() will
issue a warning then continue with the old snapshot mode instead. To
make this work, I modified pgstat_prep_snapshot to determine the
actual consistency mode to use, and then the subsequent code uses the
returned mode.

WARNING:  ignored in-transaction change of statistics consistency

The patch allows the transitions only none->cahce and none->snapshot.
To dislable all types of transitions, it seems that we need either an
additional boolean in the struct PgStat_LocalState or an additional
enumerator in the enyum PgStat_FetchConsistency to keep track of
whether pgstat_prep_snapshot() is called during the current
transaction.

What are your thoughts on this?

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center