Fix signed/unsigned integer handling in pg_restore_relation_stats()
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253462psql -h localhost -U postgresBuilt from patchset v1 (message #1), August 23, 2026 at 08:53 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253462_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253462_1 && git checkout t253462_1Patchset v1 (message #1) is on t253462_1
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.
Attachments:
t253462_10001-Fix-signed-unsigned-integer-handling-in-pg_restore_r.patchtext/plain; charset=UTF-8; name=0001-Fix-signed-unsigned-integer-handling-in-pg_restore_r.patchDownload+12-34
0002-doc-Document-overflow-handling-of-pg_class.relpages-.patchtext/plain; charset=UTF-8; name=0002-doc-Document-overflow-handling-of-pg_class.relpages-.patchDownload+12-1
On Aug 18, 2026, at 16:36, Peter Eisentraut <peter@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);
```
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/