Обсуждение: 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
takea 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
thischange should be safe. 

For pgstat_reset_database_timestamp(), in most paths dboid is also just MyDatabaseId. However, there is one path where
dboidcan 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
functionignores dboid and uses MyDatabaseId, calling pg_stat_reset_single_table_counters() on a shared relation can
incorrectlyreset 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/

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] 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

> 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_resettimestamp. 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)
checkin v1. With the v2 patch, the test passes. 

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

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/