On Tue, Mar 10, 2026 at 3:27 PM Sami Imseih <[email protected]> wrote: > > Hi, > > Please don't top-post. it makes following the thread difficult. > > > > I also noticed that pg_statio_all_sequences does not have a reset > > > column. We should fix this one also. What do you think? > > > > Right now the pg_statio_all_tables, pg_statio_all_indexes, > > pg_statio_all_sequences, pg_stat_user_functions all do not have > > reset_stat supported. I am actively working on tadd a reset_stat > > support for these view. For now, let's quickly address the db conflict > > first. > > It looks like stats_reset for pg_stat_user_functions was added in > b71bae41a0cd and for the others you mention, expected for > pg_statio_all_sequences, was added in a5b543258aa2. > These are already targeted for 19, and you can also see > that in the devel docs [1]. > > The changes you attached in v2 look good to me, but I think > we should also add a test in stats.sql as well. > > FWIW, I find using "git format-patch" better for the threads. It > forces you to write a commit message and properly formats > the patch name [2]? It's the most common way I see patches > being submitted. > > [1] [https://www.postgresql.org/docs/devel/monitoring-stats.html] > [2] [https://wiki.postgresql.org/wiki/Submitting_a_Patch] > > -- > Sami Imseih > Amazon Web Services (AWS).
Thanks for pointing that out. I've added new tests and used git format-patch to generate a new patch.
pg_stat_database_conflicts_v3.patch
Description: Binary data
