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