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 |
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 |