Re: BUG #14206: Switch to using POSIX semaphores on FreeBSD - Mailing list pgsql-bugs

Tom,

Well, now thinking about it, no I am certainly not sure about the root
cause. Mind you, until recently I had almost 0 knowledge about use of those
by postgres and, thanks God, I never had to use SYSV IPC for anything we
develop here. We've been increasing those limits to reasonably high values
for many years on kernels that we ship just to make PG run happily. And so
except of those sporadic leftover leakage of semaphores, that we've
workaround with ipcrm, it did not bother us much. (In case it's something
you want to look into that leakage seems to be happening when postgres
crashed upon write failure when disk space runs out, last time I've seen it
happening was this spring, so it must be some of the recent revisions too)

Back to those resource shortage crashes, in fact now that you are asking,
it's certainly possibly that something went south in the kernel. We also
done OS upgrade from 10.1 to 10.3 at the same time along with minor version
of postgres refresh when those crashes started to happen. But you are
always blame the software part first, so we did and in our case
bumping the kern.ipc.semmnu
did solve it for us, so we closed the case and moved on. I might look
through the changes in the semop() between 10.1 and 10.3 to see where that
EINVAL might be coming from. However, since we are considering switching to
(un)named POSIX primitives I don't feel a strong urge to do so.

But again, on a general note this kinda underlines the fact that sysv ipc
might be seen as somewhat legacy interface by the FreeBSD kernel people.
(disclamer, this is all IMHO, not talking on behalf of the freebsd project
or any part of it)

Some of it is related to the API design flaws that Konstantin alluded to,
some of it to the fact that as far as I understand, it's separate big chunk
of kernel code created decades ago by people who might no longer be
actively involved with the project and designed to run in vastly different
hardware and software environment. Nobody really owns it and it's not easy
to regression test. In my own limited experience if not for postgresql, we
would not even have that SYSV IPC enabled in our production kernels. And we
use some other 300+ opensource packages in our product, so sample is quite
representative I think.

On the other hand, as far as I understood from Konstantin's explanations,
POSIX primitives share most of the code with pthread library and as such
it's mostly modern code, well maintained, production and regression tested
and continuously optimized to run on modern things.

The point here that I am trying to make, perhaps postgres developers need
to acknowledge that clinging to SYSV IPC these days as the only supported
choice for synchronization is like using say sbrk(2) or mmap(2) to manage
heap instead of malloc(3). Yes, I understand that "don't touch it if it's
not broken" principle is important and yes, there might be some valid cases
where you'd want to do sbrk() or mmap too, but I also don't see any
technical reasons for not making POSIX primitives a first-class citizen in
PG either.

-Max

On Wed, Jun 22, 2016 at 9:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Maxim Sobolev <sobomax@sippysoft.com> writes:
> > From the man semopt:
> >      [EINVAL]           No semaphore set corresponds to semid, or the
> process
> >                         would exceed the system-defined limit for the
> number
> >                         of per-process SEM_UNDO structures.
>
> > AFAIK we've been hitting the second cause there. This is with FreeBSD
> 10.3
> > and postgresql 9.2.16 specifically. We've also seen this with 9.1 I
> think,
> > but I am not 100% sure. The specific limit that got exceeded
> > was kern.ipc.semmnu.
>
> We never ask semop(2) for SEM_UNDO, so are you sure this isn't a kernel
> bug?  I've never heard of such a report on any other platform.
>
>                         regards, tom lane
>