Re: BUG #17804: Assertion failed in pg_stat after fetching from pg_stat_database and switching cache->snapshot
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: exclusion@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Date: 2023-04-28T01:41:00Z
Lists: pgsql-bugs
Attachments
- v2-01-fix-pgstat-sfc.patch (text/x-patch) patch v2
At Thu, 27 Apr 2023 13:00:00 +0300, Alexander Lakhin <exclusion@gmail.com> wrote in > Hello, > > 24.02.2023 19:00, Alexander Lakhin wrote: > > 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)? Thank you for the patch. (Sorry, I forgot about this..) > Please look at the attached patch, which implements that idea and also > includes a simple test. The behavior change doesn't affect any of > existing > tests and seems natural to me, so I haven't added a note about it in > the docs. I tried to keep existing snapshots as long as possible, but considering how rarely users change the variable and the lack of necessity to to preserve the snapshots, it's simply easier to clear them with each variable change. Nonetheless, I'm a bit concerned about making a direct call to pgstat_clear_snapshot() from the assign callback, it might be fine for now, but I worry that it could an issue later on. So, how about just settin a trigger that causes a snapshot clearing prior to the next use, like the attached? As for the test, I can't come up with a better one, but I think the comment should explain its intention more clearly. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
Commits
-
Fix assertion failure when updating stats_fetch_consistency in a transaction
- ccd21e1cfa11 15.4 landed
- 605994651b6a 16.0 landed
-
Document values of stats_fetch_consistency in postgresql.conf.sample
- 4d47eff99cc0 16.0 landed