> On Mar 12, 2026, at 12:50, Fujii Masao <[email protected]> wrote:
>
> On Wed, Mar 11, 2026 at 11:10 PM shihao zhong <[email protected]> wrote:
>> Thanks for pointing that out. I've added new tests and used git
>> format-patch to generate a new patch.
>
> Thanks for updating the patch!
>
> +-- Test that the stats_reset column in pg_stat_database_conflicts is
> correctly maintained
> +SELECT pg_stat_reset();
> +SELECT stats_reset IS NOT NULL AS has_stats_reset
> + FROM pg_stat_database_conflicts WHERE datname = current_database();
>
> Since stats.sql already includes tests verifying that reset works for
> pg_stat_database, it might be better to add the test for
> pg_stat_database_conflicts alongside those, rather than at the end of
> stats.sql. Thought? The attached updated patch does that.
>
> I also fixed some indentation issues in the docs in the patch.
>
> Regards,
>
> --
> Fujii Masao
> <v4-0001-Add-stats_reset-column-to-pg_stat_database_confli.patch>
V4 overall LGTM. A couple of nitpicks:
1 - stats.sql
```
+WHERE D.datname = (SELECT current_database()) AND D.datname = DC.datname \gset
+WHERE D.datname = (SELECT current_database()) AND D.datname = DC.datname;
```
(SELECT current_database()) can be just current_database(). I tried to fix this
in my local, and the fix works for me.
2 - stats.sql
```
+-- Since stats_reset in pg_stat_database and pg_stat_database_conflicts starts
+-- out as NULL, reset it once first so we have something to compare it to
```
I think “starts” should be “start”, because there are two stats_reset fields
from two tables in this context.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
