Re: backends stuck in "startup"

On 2017-11-21 19:02:01 -0500, Tom Lane wrote:
> andres(at)anarazel(dot)de (Andres Freund) writes:
> > On 2017-11-21 18:50:05 -0500, Tom Lane wrote:
> >> (If Justin saw that while still on 9.6, then it'd be worth looking
> >> closer.)
>
> > Right. I took this to be referring to something before the current
> > migration, but I might have overinterpreted things. There've been
> > various forks/ports of pg around that had hand-coded replacements with
> > futex usage, and there were definitely buggy versions going around a few
> > years back.
>
> Poking around in the archives reminded me of this thread:
> https://www.postgresql.org/message-id/flat/14947(dot)1475690465(at)sss(dot)pgh(dot)pa(dot)us
> which describes symptoms uncomfortably close to what Justin is showing.
>
> I remember speculating that the SysV-sema implementation, because it'd
> always enter the kernel, would provide some memory barrier behavior
> that POSIX-sema code based on futexes might miss when taking the no-wait
> path.

I think I was speculating that, but with the benefit of just having had
my fourth espresso: I've a hard time believing that - the fast path in a
futex pretty much has to be either a test-and-set or a
compare-and-exchange type operation. See e.g. the demo of futex usage in
the futex(2) manpage:

while (1) {
/* Is the futex available? */
if (__sync_bool_compare_and_swap(futexp, 1, 0))
break; /* Yes */

/* Futex is not available; wait */
s = futex(futexp, FUTEX_WAIT, 0, NULL, NULL, 0);
if (s == -1 && errno != EAGAIN)
errExit("futex-FUTEX_WAIT");
}

I can't see how you could make use of futexes without some kind of
barrier semantics, at least on x86.

Greetings,

Andres Freund