Re: PostgreSQL performance on FreeBSD

Konstantin,

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)
                        break;
#else
                if (mySem != (sem_t *) (-1))
                        break;
#endif

                /* Loop if error indicates a collision */
                if (errno == EEXIST || errno == EACCES || errno == EINTR)
                        continue;

                /*
                 * Else complain and abort
                 */
                elog(FATAL, "sem_open(\"%s\") failed: %m", semname);
        }

        /*
         * Unlink the semaphore immediately, so it can't be accessed
externally.
         * This also ensures that it will go away if we crash.
         */
        sem_unlink(semname);

        return mySem;
----

-Max

On Wed, Jun 22, 2016 at 3:02 AM, Konstantin Belousov <kostikbel_at_gmail.com>
wrote:

> On Tue, Jun 21, 2016 at 12:48:00PM -0700, Maxim Sobolev wrote:
> > Thanks, Konstantin for the great work, we are definitely looking forward
> to
> > 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
> sent.
>
> >
> > Just in case, I've opened #14206 with PG to switch us to using POSIX
> > semaphores by default. Apart from the mentioned performance benefits,
> SYSV
> > semaphores are PITA to deal with as they come in very limited quantities
> by
> > 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
> that.
> > I am happy that code could be retired now.
>
> Named semaphores also stuck around if processes are killed without cleanup.
>
>