Re: Fix pgstat_database.c to honor passed database OIDs - Mailing list pgsql-hackers

> On Apr 10, 2026, at 15:56, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Fri, Apr 10, 2026 at 03:12:41PM +0900, Michael Paquier wrote:
>> If we decide to expand pgstat_reset() in other contexts in the
>> back-branches, we'd be silently trapped as well.
>>
>> The connect and disconnect calls are less critical, perhaps we could
>> remove the argument altogether, but I cannot get excited about that
>> either as some extensions may rely on these as currently designed.
>>
>> I cannot look at that today, will do so later..
>
> -    dbref = pgstat_get_entry_ref_locked(PGSTAT_KIND_DATABASE, MyDatabaseId, InvalidOid,
> +    if (!OidIsValid(dboid))
> +        return;
> +
> +    dbref = pgstat_get_entry_ref_locked(PGSTAT_KIND_DATABASE, dboid, InvalidOid,
>                                         false);
>
> This bypass of an invalid database OID is actually incorrect in the
> patch.  There is a stats entry with a database OID of 0, documented as
> such in [1] for shared objects.  There is one test in the main
> regression test suite that triggers this case:
> SELECT pg_stat_reset_single_table_counters('pg_shdescription'::regclass);
>
> The short answer is to remove this check based on OidIsValid(), and
> allow the timestamp be reset for this entry of 0 rather than ignore
> the update.
>
> [1]: https://www.postgresql.org/docs/devel/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW
> --
> Michael

Thanks for pointing out the test. I badly excluded *.sql and *.out in my vscode search last time.

Then the question becomes why the test didn't fail. I looked into it, and it seems the existing test does not check the stats_reset timestamp. I have now added checks for the stats_reset of both database 0 and the current database.

With those checks in place, the test fails without this patch, and also fails with the incorrect OidIsValid(dboid) check in v1. With the v2 patch, the test passes.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

Hi Evan,

I tested the v2 patch on HEAD. It applies cleanly, compiles
without warnings, and all 247 regression tests pass.

I also manually verified the bug fix by comparing behavior
before and after the patch:

Without the patch, calling
pg_stat_reset_single_table_counters('pg_shdescription'::regclass)
incorrectly updates the current database's stats_reset timestamp
while leaving the shared db entry (datid=0) unchanged.

With the patch, the shared db entry's stats_reset is correctly
updated, and the current database's timestamp is not affected.

Regards,