Re: Fix signed/unsigned integer handling in pg_restore_relation_stats()

[Peter Eisentraut]

On 20.08.26 04:08, Chao Li wrote:

On Aug 18, 2026, at 16:36, Peter Eisentraut <pe...@eisentraut.org> wrote:

The pg_class fields relpages, relallvisible, and relallfrozen are of
type int32, but the statistics restoration code internally dealt with them as 
uint32 for a little bit, after which they would turn back into int32.  This all 
happens to work, but it doesn't make sense, so I propose the attached fix.

While researching this, I noticed that we don't appear to document how 
page/block counts larger than INT32_MAX are represented in the catalogs.  A C 
programmer would have a certain expectation, but we shouldn't expect everyone 
to guess that.  So I'm proposing a small addition to the catalog documentation 
to clarify this.
<0001-Fix-signed-unsigned-integer-handling-in-pg_restore_r.patch><0002-doc-Document-overflow-handling-of-pg_class.relpages-.patch>

Overall looks good to me. Only one small comment on 0001:
```
--- a/src/backend/statistics/relation_stats.c
+++ b/src/backend/statistics/relation_stats.c
@@ -99,13 +99,13 @@ relation_statistics_update(FunctionCallInfo fcinfo)
  static bool
  relation_statistics_update_internal(Oid reloid, FunctionCallInfo fcinfo)
  {
-       BlockNumber relpages = 0;
+       int32           relpages = 0;
```

relpages is changed to int32, so the later code of 
PG_GETARG_UINT32(RELPAGES_ARG) to PG_GETARG_INT32.
```
        if (!PG_ARGISNULL(RELPAGES_ARG))
        {
                relpages = PG_GETARG_UINT32(RELPAGES_ARG);
```

Thanks.  Committed with that change and some further polishing.