Hi,
Just to follow up — in our production system (pg_cron extension), we’ve encountered real issues caused by passing a `Datum` to `dsm_attach()` using `DatumGetInt32()` instead of `DatumGetUInt32()`.
Here's a sample of the errors observed in our logs:
ERROR: unable to map dynamic shared memory segment
WARNING: one or more background workers failed to start
These errors trace back to failures in `dsm_attach()`, where the segment handle value was incorrectly interpreted due to sign extension from `int32`.
The patch proposed earlier resolves this issue by correctly using `DatumGetUInt32()`.
Thanks,
Jianghua yang
On Thu, Jun 26, 2025 at 12:51:10PM -0700, Jianghua Yang wrote:
> The argument passed to `dsm_attach()` is expected to be a `uint32`, but the
> code currently uses `DatumGetInt32()` to extract it from the `Datum`
> argument. This can lead to incorrect behavior when the high bit is set, as
> 'unable to map dynamic shared memory segment'.
I'm not sure this actually causes any problems in practice because
dsm_attach() treats its argument as unsigned. In any case, I've never seen
this test fail like that, and presumably the high bit is sometimes set
because the handle is generated with a PRNG.
Nevertheless, I see no point in using the wrong macro. I'll plan on
committing/back-patching this shortly.
--
nathan
