PostgreSQL used SYSV because it allowed for the detection of dead processes.
If you `kill -9`’ed a process, PostgreSQL can detect that and then shut down
and perform an automatic recovery. In this regard, sysv is pretty clever. The
move to POSIX shared mem was done for a host of reasons, but it means that you
don’t have to adjust your SYSV limits. My understanding from a few years ago
is that there is still a ~64KB SYSV memory segment that is still used to act as
the latch to signal if a process was killed, but all of the shared buffers are
stored in posix mmap’ed regions.
At this point in time this could be replaced with kqueue(2) EVFILT_PROC, but no
one has done that yet.
> On Jun 22, 2016, at 07:26 , Maxim Sobolev <sobo...@freebsd.org> wrote:
> Not if you do sem_unlink() immediately, AFAIK. And that's what PG does. So
> the window of opportunity for the leakage is quite small, much smaller than
> for SYSV primitives. Sorry for missing your status update message, I've
> missed it somehow.
> mySem = sem_open(semname, O_CREAT | O_EXCL,
> (mode_t) IPCProtection,
> (unsigned) 1);
> #ifdef SEM_FAILED
> if (mySem != (sem_t *) SEM_FAILED)
> if (mySem != (sem_t *) (-1))
> /* Loop if error indicates a collision */
> if (errno == EEXIST || errno == EACCES || errno == EINTR)
> * Else complain and abort
> elog(FATAL, "sem_open(\"%s\") failed: %m", semname);
> * Unlink the semaphore immediately, so it can't be accessed
> * This also ensures that it will go away if we crash.
> return mySem;
> On Wed, Jun 22, 2016 at 3:02 AM, Konstantin Belousov <kostik...@gmail.com>
>> On Tue, Jun 21, 2016 at 12:48:00PM -0700, Maxim Sobolev wrote:
>>> Thanks, Konstantin for the great work, we are definitely looking forward
>>> get all those improvements to be part of the default FreeBSD kernel/port.
>>> Would be nice if you can post an update some day later as to what's
>>> integrated and what's not.
>> I did posted the update several days earlier. Since you replying to this
>> thread, it would be not unreasonable to read recent messages that were
>>> Just in case, I've opened #14206 with PG to switch us to using POSIX
>>> semaphores by default. Apart from the mentioned performance benefits,
>>> semaphores are PITA to deal with as they come in very limited quantities
>>> default. Also they might stay around if PG dies/gets nuked and prevent it
>>> from starting again due to overflow. We've got some quite ugly code to
>>> clean up those using ipcrm(1) in our build scripts to deal with just
>>> I am happy that code could be retired now.
>> Named semaphores also stuck around if processes are killed without cleanup.
> freebsd-performa...@freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"