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

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17804: Assertion failed in pg_stat after fetching from pg_stat_database and swithing cache->snapshot
Date: 2023-02-24 07:08:12
Message-ID: 20230224.160812.1001813717917457753.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

At Wed, 22 Feb 2023 06:00:01 +0000, PG Bug reporting form <noreply(at)postgresql(dot)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

Attachment Content-Type Size
pgstat_reject_inconsistent_consistency_mode_change.diff text/x-patch 7.0 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Dean Rasheed 2023-02-24 08:50:45 Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values
Previous Message 小杨 2023-02-24 03:22:35 pg_upgrade does not support a table 2 in the original database to inherit from table 1 (field F_Test1 is not empty), and then table 2 modifies F by itself_ Test1 is nullable