[PATCH] Fix argument in pg_indexam_progress_phasename()
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.
This thread has been committed, so CI has stopped here. Anything below is the last result it produced.
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:t254303psql -h localhost -U postgresBuilt from patchset v1 (message #1), October 21, 2026 at 02:31 PM.
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 t254303_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 t254303_1 && git checkout t254303_1Patchset v1 (message #1) is on t254303_1
Hello,
There is a oversight in pg_indexam_progress_phasename() since ab0dfc961b6 where the second argument is declared int8 in pg_proc.dat but gotten via PG_GETARG_INT32() in the C code.
This isn't much of a problem since 2a600a93c7b where Datums became 8 byte wide everywhere. However, this is an actual problem in 32-bit architecture in older PostgreSQL versions where int8 is passed by reference and returns bogus numbers. The side effect is that pg_stat_progress_create_index never shows the access method phasename. This should probably be backpatched.
--
Markos Fountoulakis
PlanetScale Postgres Core Team
On Oct 21, 2026, at 22:15, Markos Fountoulakis <markos@planetscale.com> wrote:
Hello,
There is a oversight in pg_indexam_progress_phasename() since ab0dfc961b6 where the second argument is declared int8 in pg_proc.dat but gotten via PG_GETARG_INT32() in the C code.
Good catch. pg_proc.dat defines the second argument as int8, and the AM callback also takes int64:
```
/* name of phase as used in progress reporting */
typedef char *(*ambuildphasename_function) (int64 phasenum);
```
pg_indexam_progress_phasename(), which sits between these two layers, should also use int64. So the patch looks correct to me.
This isn't much of a problem since 2a600a93c7b where Datums became 8 byte wide everywhere. However, this is an actual problem in 32-bit architecture in older PostgreSQL versions where int8 is passed by reference and returns bogus numbers. The side effect is that pg_stat_progress_create_index never shows the access method phasename. This should probably be backpatched.
On older 32-bit builds, int8 arguments are passed by reference, so with PG_GETARG_INT32, pg_indexam_progress_phasename() would interpret a pointer value as phasenum. This makes me wonder whether we should add a simple test for this function. If there were such a test, I would have expected the CI to catch this bug, since I believe it includes 32-bit builds.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
On Thu, Oct 22, 2026 at 08:31:19AM +0800, Chao Li wrote:
pg_indexam_progress_phasename(), which sits between these two
layers, should also use int64. So the patch looks correct to me.
Yep, nice catch. This warrants a backpatch. Will fix, thanks for the
report.
--
Michael