Re: [PATCH] Fix argument in pg_indexam_progress_phasename()

> On Oct 21, 2026, at 22:15, Markos Fountoulakis <markos(at)planetscale(dot)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/