s/shm_mq_iovec/struct iovec/
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t49460psql -h localhost -U postgresBuilt from patchset v1 (message #1), October 06, 2026 at 07:47 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t49460_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t49460_1 && git checkout t49460_1Patchset v1 (message #1) is on t49460_1
Hi,
I was grepping for iovec users and noticed that the shm_mq stuff
defines its own iovec struct. Is there any reason not to use the
standard one, now that we can? Will add to next commitfest.
On 15/04/2024 04:20, Thomas Munro wrote:
Hi,
I was grepping for iovec users and noticed that the shm_mq stuff
defines its own iovec struct. Is there any reason not to use the
standard one, now that we can? Will add to next commitfest.
I think it's better to keep them separate. They serve a similar purpose,
but they belong to completely separate APIs; I think "incidental
deduplication" is the right term for that. shm_mq_iovec is only used by
our shm queue implementation, while struct iovec is part of the POSIX
API. We wouldn't want to leak IOV_MAX into how shm_mq_iovec is used, for
example. Or as a thought experiment, if our shm_mq implementation needed
an extra flag in the struct or something, we would be free to just add
it. But if it we reused struct iovec, then we couldn't, or we'd need to
create a new struct again.
--
Heikki Linnakangas
Neon (https://neon.tech)
On Thu, Jul 4, 2024 at 9:26 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
On 15/04/2024 04:20, Thomas Munro wrote:
I was grepping for iovec users and noticed that the shm_mq stuff
defines its own iovec struct. Is there any reason not to use the
standard one, now that we can? Will add to next commitfest.I think it's better to keep them separate. They serve a similar purpose,
but they belong to completely separate APIs; I think "incidental
deduplication" is the right term for that. shm_mq_iovec is only used by
our shm queue implementation, while struct iovec is part of the POSIX
API. We wouldn't want to leak IOV_MAX into how shm_mq_iovec is used, for
example. Or as a thought experiment, if our shm_mq implementation needed
an extra flag in the struct or something, we would be free to just add
it. But if it we reused struct iovec, then we couldn't, or we'd need to
create a new struct again.
Thanks for looking. I marked this "returned with feedback".
(For future parallel query work, I have a scheme where queues can
spill to disk instead of blocking, which unblocks a bunch of parallel
execution strategies that are currently impossible due to flow control
deadlock risk. Then the two APIs meet and it annoys me that they are
not the same, so maybe I'll talk about this again some day :-))