Re: BUG #14960: Queries stuck on BtreePage lock on parallel index scan

On Mon, Dec 11, 2017 at 10:22 PM, <tlw(at)monsido(dot)com> wrote:
> The following bug has been logged on the website:
>
> Bug reference: 14960
> Logged by: Tim Warberg
> Email address: tlw(at)monsido(dot)com
> PostgreSQL version: 10.1
> Operating system: Ubuntu 16.04 LTS
> Description:
>
> Hi,
>
> Ran into a issue on our PostgreSQL 10.1 cluster that seems to be a parallel
> index scan bug. Our queue system scheduled 30 almost identical concurrent
> queries where some of them was executed as parallel queries and all of them
> became stuck on IPC BtreePage lock.

Hi Tim,

Thanks for the report. This seems to be the same as the bug that we
just analysed over here:

https://www.postgresql.org/message-id/flat/CAEepm%3D2xZUcOGP9V0O_G0%3D2P2wwXwPrkF%3DupWTCJSisUxMnuSg%40mail.gmail.com

> We discovered this after they've been
> stuck like that for about 10 hours [1]. At the same time a autovacuum was
> progressing one of the queried tables and it had become stuck in LWLock
> buffer_content while vacuuming indexes. None of the query processes
> responded to pg_cancel_backend nor pg_terminate_backend including the
> autovacuum.

Hmm. This may be because we hold a BT_READ lock while waiting in
_bt_parallel_seize(). Here it's extended by the above-mentioned bug,
preventing others from acquiring an exclusive lock.

--
Thomas Munro
http://www.enterprisedb.com