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

From Michael Paquier
Subject Re: Fix pgstat_database.c to honor passed database OIDs
Date
Msg-id aditMVNDceHtvYj4@paquier.xyz
Whole thread Raw
In response to Re: Fix pgstat_database.c to honor passed database OIDs  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Fix pgstat_database.c to honor passed database OIDs
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Dapeng Wang
Date:
Subject: Re: Docs: Create table description for constraints markup fix and label tweaks
Next
From: Thomas Munro
Date:
Subject: Re: pg_waldump: support decoding of WAL inside tarfile