PostgreSQL performance on FreeBSD
sobomax at freebsd.org
Wed Jun 22 14:26:54 UTC 2016
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,
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.
On Wed, Jun 22, 2016 at 3:02 AM, Konstantin Belousov <kostikbel at 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.
More information about the freebsd-performance