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

Поиск
Список
Период
Сортировка
От Alexander Lakhin
Тема Re: BUG #17804: Assertion failed in pg_stat after fetching from pg_stat_database and switching cache->snapshot
Дата
Msg-id 1836967a-9f78-aed8-1ff1-3351c504e8f0@gmail.com
обсуждение исходный текст
Ответ на Re: BUG #17804: Assertion failed in pg_stat after fetching from pg_stat_database and swithing cache->snapshot  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Ответы Re: BUG #17804: Assertion failed in pg_stat after fetching from pg_stat_database and switching cache->snapshot  (Alexander Lakhin <exclusion@gmail.com>)
Список 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



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17806: PostgreSQL 13.10 returns "CREATE DATABASE cannot be executed within a pipeline"
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values