Re: [PATCH] Use DatumGetUInt32() for dsm_attach() in test_shm_mq_main()
От | Nathan Bossart |
---|---|
Тема | Re: [PATCH] Use DatumGetUInt32() for dsm_attach() in test_shm_mq_main() |
Дата | |
Msg-id | aF28yOnSISsZCCYr@nathan обсуждение исходный текст |
Ответ на | Re: [PATCH] Use DatumGetUInt32() for dsm_attach() in test_shm_mq_main() (Jianghua Yang <yjhjstz@gmail.com>) |
Ответы |
Re: [PATCH] Use DatumGetUInt32() for dsm_attach() in test_shm_mq_main()
|
Список | 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
В списке pgsql-hackers по дате отправления: