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

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(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 switching cache->snapshot
Date: 2023-02-24 16:00:00
Message-ID: 1836967a-9f78-aed8-1ff1-3351c504e8f0@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2023-02-24 16:53:45 Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values
Previous Message Tom Lane 2023-02-24 15:56:34 Re: BUG #17806: PostgreSQL 13.10 returns "CREATE DATABASE cannot be executed within a pipeline"