On Mon, Mar 16, 2026 at 5:27 PM Fujii Masao <[email protected]> wrote: > > On Fri, Mar 13, 2026 at 11:52 AM Sami Imseih <[email protected]> wrote: > > > > > it would be better to verify that the stats of the specified sequence are > > > actually reset by using pg_stat_reset_single_table_counters(). > > > > > > Also, the documentation for pg_stat_reset_single_table_counters() should > > > mention that it can reset sequence statistics as well. > > > > good points. > > > > For the documentation of pg_stat_reset_single_table_counters(), I also > > mentioned materialized views for completeness. > > Thanks for updating the patch! > > I made a few cosmetic changes and pushed the patch. Thanks!
Hmm... buildfarm member crake reported a pg_upgradeCheck failure, and it seems the test I added last time is causing it :( --- /home/andrew/bf/root/HEAD/pgsql/src/test/regress/expected/stats.out 2026-03-16 04:27:05.805748763 -0400 +++ /home/andrew/bf/root/HEAD/pgsql.build/testrun/pg_upgrade/002_pg_upgrade/data/results/stats.out 2026-03-16 05:17:15.460202339 -0400 @@ -1196,7 +1196,7 @@ FROM pg_statio_all_sequences WHERE relname ='test_seq1'; ?column? | ?column? ----------+---------- - t | 0 + t | 1 (1 row) The test assumed that blks_read and blks_hit in pg_statio_all_sequences would be zero immediately after calling pg_stat_reset_single_table_counters(). However, on crake, either of them became 1 even right after the reset. This might happen if another process (e.g., autovacuum) accesses the sequence in the short window between the reset and the query of pg_statio_all_sequences??? More investigation would be necessary. Since checking the blks_read and blks_hit counters in pg_statio_all_sequences can make the test unstable, I'm thinking of removing that part of the test. Regards, -- Fujii Masao
