> On Aug 18, 2026, at 16:36, Peter Eisentraut <[email protected]> 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);
```
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
