Re: [PATCH] Use DatumGetUInt32() for dsm_attach() in test_shm_mq_main()

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Jianghua Yang <yjhjstz(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] Use DatumGetUInt32() for dsm_attach() in test_shm_mq_main()
Date: 2025-06-26 21:34:00
Message-ID: aF28yOnSISsZCCYr@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 26, 2025 at 01:46:10PM -0700, Jianghua Yang wrote:
> 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`.

I think there might be something else going on. I added a debug log in
test_shm_mq, and it looks like it regularly uses handles with the high bit
set. I also wrote a test program and consulted the C standard, which seem
to confirm that passing a signed integer to a function with an unsigned
parameter leaves the high bit set.

--
nathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jelte Fennema-Nio 2025-06-26 22:04:24 Re: Correct documentation for protocol version
Previous Message Daniel Gustafsson 2025-06-26 21:06:50 Re: Adding support for SSLKEYLOGFILE in the frontend