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

On 20.08.26 04:08, Chao Li wrote:
>
>
>> On Aug 18, 2026, at 16:36, Peter Eisentraut <peter(at)eisentraut(dot)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.