From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | |
Cc: | andres(at)anarazel(dot)de (Andres Freund), Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: backends stuck in "startup" |
Date: | 2017-11-22 00:16:00 |
Message-ID: | 8341.1511309760@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I wrote:
> ... Maybe we need
> to take a closer look at where LWLocks devolve to blocking on the process
> semaphore and see if there's any implicit assumptions about barriers there.
Like, say, here:
for (;;)
{
PGSemaphoreLock(proc->sem);
if (!proc->lwWaiting)
break;
extraWaits++;
}
which is exactly where Justin's backend is stuck. Without a read barrier
after the PGSemaphoreLock, it seems possible that we might not see our
lwWaiting as cleared yet, causing the loop to go around an extra time and
wait for a sema wakeup that will never come. Then, we are holding the
lock but are blocked anyway, and everyone else who wants that same lock
will queue up behind us.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Rakesh Kumar | 2017-11-22 00:37:06 | Re: backends stuck in "startup" |
Previous Message | Andres Freund | 2017-11-22 00:11:00 | Re: backends stuck in "startup" |