> On Oct 21, 2026, at 22:15, Markos Fountoulakis <[email protected]> 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/
