Fix pgstat_database.c to honor passed database OIDs
Hi,
In pgstat_database.c, pgstat_report_connect(), pgstat_report_disconnect(), and pgstat_reset_database_timestamp() all take a dboid parameter, but currently ignore it and use MyDatabaseId instead. While that does not seem to break anything today, it at least hurts readability.
This patch changes those three functions to use the passed dboid.
For pgstat_report_connect() and pgstat_report_disconnect(), there is only one caller, and it passes MyDatabaseId, so this change should be safe.
For pgstat_reset_database_timestamp(), in most paths dboid is also just MyDatabaseId. However, there is one path where dboid can be InvalidOid:
1 - pg_stat_reset_single_table_counters may pass InvalidOid to pgstat_reset for a shared relation.
```
Datum
pg_stat_reset_single_table_counters(PG_FUNCTION_ARGS)
{
Oid taboid = PG_GETARG_OID(0);
Oid dboid = (IsSharedRelation(taboid) ? InvalidOid : MyDatabaseId);
pgstat_reset(PGSTAT_KIND_RELATION, dboid, taboid);
PG_RETURN_VOID();
}
```
2 - pgstat_reset only calls pgstat_reset_database_timestamp when kind_info->accessed_across_databases is false.
```
void
pgstat_reset(PgStat_Kind kind, Oid dboid, uint64 objid)
{
const PgStat_KindInfo *kind_info = pgstat_get_kind_info(kind);
TimestampTz ts = GetCurrentTimestamp();
/* not needed atm, and doesn't make sense with the current signature */
Assert(!pgstat_get_kind_info(kind)->fixed_amount);
/* reset the "single counter" */
pgstat_reset_entry(kind, dboid, objid, ts);
if (!kind_info->accessed_across_databases)
pgstat_reset_database_timestamp(dboid, ts);
}
```
3 - In this path, kind is PGSTAT_KIND_RELATION, and accessed_across_databases is false:
```
[PGSTAT_KIND_RELATION] = {
.name = "relation",
.fixed_amount = false,
.write_to_file = true,
.shared_size = sizeof(PgStatShared_Relation),
.shared_data_off = offsetof(PgStatShared_Relation, stats),
.shared_data_len = sizeof(((PgStatShared_Relation *) 0)->stats),
.pending_size = sizeof(PgStat_TableStatus),
.flush_pending_cb = pgstat_relation_flush_cb,
.delete_pending_cb = pgstat_relation_delete_pending_cb,
.reset_timestamp_cb = pgstat_relation_reset_timestamp_cb,
},
```
So in this case, pgstat_reset_database_timestamp() can receive InvalidOid as dboid. In the current code, because that function ignores dboid and uses MyDatabaseId, calling pg_stat_reset_single_table_counters() on a shared relation can incorrectly reset the current database's stat_reset_timestamp. That behavior seems unintended, so this patch makes pgstat_reset_database_timestamp() return immediately when dboid is InvalidOid.
Please see the attached patch. “Make check-world” passed from my side.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
Attachments:
v1-0001-Fix-pgstat_database.c-to-honor-passed-database-OI.patchapplication/octet-stream; name=v1-0001-Fix-pgstat_database.c-to-honor-passed-database-OI.patch; x-unix-mode=0644Download+6-4
On Fri, Apr 10, 2026 at 01:53:15PM +0800, Chao Li wrote:
For pgstat_reset_database_timestamp(), in most paths dboid is also
just MyDatabaseId. However, there is one path where dboid can be
InvalidOid:
The call of pgstat_reset_database_timestamp() in pgstat_reset() is a
bug that has to be backpatched down to v15. It does not make sense to
let a caller of pgstat_reset() pass down a custom dboid and then
decide to reset the timestamp of MyDatabaseId instead. The call of
pgstat_reset() in pgstat_create_transactional() is the only fishy one,
the other callers are OK.
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..
--
Michael
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]https://www.postgresql.org/docs/devel/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW -- Michael 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
--
Michael
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/
Attachments:
v2-0001-Fix-pgstat_database.c-to-honor-passed-database-OI.patchapplication/octet-stream; name=v2-0001-Fix-pgstat_database.c-to-honor-passed-database-OI.patch; x-unix-mode=0644Download+29-4
Chao Li <li.evan.chao@gmail.com> 于2026年4月10日周五 16:45写道：
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
--
MichaelThanks 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,
Dapeng Wang
On Fri, Apr 10, 2026 at 09:01:32PM +0800, Dapeng Wang wrote:
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.
The coalesce() trick to bypass the fact that the reset timestamp may
not be reset was a bit ugly, so I have used instead a second reset.
I have limited the test to check for datid=0, not MyDatabaseId.
There is a bit down in stats.sql an extra portion of the test where we
use twice pg_stats_reset(). One reset could be removed, but I have
left it as-is in case someone decides to shuffle or split things in
this test script, to avoid problems in the future.
And fixed that down to v15.
--
Michael
On Apr 13, 2026, at 08:16, Michael Paquier <michael@paquier.xyz> wrote:
On Fri, Apr 10, 2026 at 09:01:32PM +0800, Dapeng Wang wrote:
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.The coalesce() trick to bypass the fact that the reset timestamp may
not be reset was a bit ugly, so I have used instead a second reset.
I have limited the test to check for datid=0, not MyDatabaseId.There is a bit down in stats.sql an extra portion of the test where we
use twice pg_stats_reset(). One reset could be removed, but I have
left it as-is in case someone decides to shuffle or split things in
this test script, to avoid problems in the future.And fixed that down to v15.
--
Michael
Thank you very much for fixing the test and pushing the patch.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/