Re: [RFC] building postgres with meson - v12

Hi,

On 2022-08-27 11:04:47 -0700, Andres Freund wrote:
> - choice of semaphore API needs to be cleaned up, that should be easy now, but
> I thought that I needed to get a new version out first

Everytime I look at the existing selection code I get confused, which is part
of why I haven't tackled this yet.

If I understand the current logic right, we check for sem_open, sem_init if
and only if PREFERRED_SEMAPHORES is set to UNNAMED_POSIX or NAMED_POSIX (no
template defaults to named). Which also means that we don't link in rt or
pthread if USE_*_POSIX_SEMAPHORES is set directly in the template, as darwin
does.

I read the configure.ac code combined with the templates as resulting in the
following precedence order:

1) windows uses windows semaphores

2) freebsd, linux use unnamed posix semaphores if available

3) macOS < 10.2 uses named semaphores, without linking in rt/pthread
4) macos >= 10.2 uses sysv semaphores

5) sysv semaphores are used

Correct?

Given that Mac OS 10.2 was released in 2002, I think we can safely consider
that unsupported - even prairiedog was a few years younger... :). Given the
downsides of named semaphores and that we apparently haven't used that code in
years, I wonder if we should remove it?

However, there has been a thread about defaulting to named semas on openbsd,
but then Tom benchmarked out that that's not going to fly for performance
reasons ([1]).

FWIW, I did notice that netbsd does have working unnamed semaphores. I don't
know how long ago they were added, but they apparently didn't work quite right
in 2018 [1]. No meaningful performance chance in the main regression tests,
I'll run a concurrent check world comparison in the background...

Should the choice be configurable with meson? I'm inclined to say not for now.

Regards,

Andres

[1] https://postgr.es/m/3010886.1634950831%40sss.pgh.pa.us
[2] http://www.polarhome.com/service/man/?qf=sem_init&tf=2&of=NetBSD&sf=3