Re: [PATCH] Make ENOSPC not fatal in semaphore creation - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: [PATCH] Make ENOSPC not fatal in semaphore creation
Date
Msg-id CA+hUKG+9uSLQCGT06nANFdam2m+iuSKEyL7SzRbyXCx8g8oesg@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Make ENOSPC not fatal in semaphore creation  (Mikhail <mp39590@gmail.com>)
Responses Re: [PATCH] Make ENOSPC not fatal in semaphore creation  (Mikhail <mp39590@gmail.com>)
Re: [PATCH] Make ENOSPC not fatal in semaphore creation  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Mon, Oct 18, 2021 at 4:49 AM Mikhail <mp39590@gmail.com> wrote:
> The logic works - the initial call to semget() in
> InternalIpcSemaphoreCreate returns -1 and errno is set to ENOSPC - I
> tested the patch on OpenBSD 7.0, it successfully recycles sem's after
> previous "pkill -6 postgres". Verified it with 'ipcs -s'.

Since you mentioned OpenBSD, what do you think of the idea of making
named POSIX semas the default on that platform?  You can't run out of
those practically speaking, but then you get lots of little memory
mappings (from memory, at least it does close the fd for each one,
unlike some other OSes where we wouldn't want to use this technique).
Trivial patch:

https://www.postgresql.org/message-id/CA%2BhUKGJVSjiDjbJpHwUrvA1TikFnJRfyJanrHofAWhnqcDJayQ%40mail.gmail.com

No strong opinion on the tradeoffs here, as I'm not an OpenBSD user,
but it's something I think about whenever testing portability stuff
there and having to adjust the relevant sysctls.

Note: The best kind would be *unnamed* POSIX semas, where we get to
control their placement in existing memory; that's what we do on Linux
and FreeBSD.  They weren't supported on OpenBSD last time we checked:
it rejects requests for shared ones.  I wonder if someone could
implement them with just a few lines of user space code, using atomic
counters and futex() for waiting.



pgsql-hackers by date:

Previous
From: Vik Fearing
Date:
Subject: Re: [PATCH] Proposal for HIDDEN/INVISIBLE column
Next
From: Tomas Vondra
Date:
Subject: Re: XTS cipher mode for cluster file encryption