Hello,
The problem seems to be resolved so this is just an additional
piece of information.
At Tue, 11 Jul 2017 09:39:17 -0700, Jeff Janes <jeff.janes@gmail.com> wrote in
<CAMkU=1zV8rvpUUXd7Bgt53HtOEtBnUXok76RwfWAJBprO-+5Bg@mail.gmail.com>
> On Tue, Jul 11, 2017 at 3:01 AM, Kyotaro HORIGUCHI <
> horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> > I'm not sure why it didn't happen on 9.3,
>
>
> In 9.3, the AccessExclusiveLock is obtained by polling. If it can never
> get the lock, it won't stop other processes from getting an
> AccessShareLock, so it won't block their ability to log on. (Once
> max_standby_streaming_delay expires, it will then slaughter everything and
> take its lock.) In 9.6, it is obtained in the more conventional way, by
> waiting while blocking newcomers who want a conflicting version. I don't
> understand exactly why this change leads to the reported behavior, but it
> is probably related.
37c54863cf7 seems that. One major behavioral difference it makes
would be the precedence of waiters. Before the patch additional
read locks have precedence to an exlusive lock even for read
locks comes after the exlusive lock (I suppose that this causes
the "spurious waits") because only the read locks are in the
waiting queue. After the patch, the exlusive lock goes into the
queue so no later read lock can break into the queue before the
exlusive lock.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs