Re: BUG #15585: infinite DynamicSharedMemoryControlLock waiting in parallel query

Thomas Munro <thomas.munro@enterprisedb.com>

From: Thomas Munro <thomas.munro@enterprisedb.com>
To: sk@zsrv.org, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2019-01-11T05:16:27Z
Lists: pgsql-bugs
On Fri, Jan 11, 2019 at 10:04 AM Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> I am trying to reproduce it.

I ran squillions of concurrent parallel queries today, making sure
they would allocate and free entire segments a lot (based on the
assumption that something along those lines must be required).  I made
sure to use Linux, GCC, -O2, no asserts (since both reports came from
that environment, and I'd previously failed to reproduce this on my
usual tool chain/platforms), and I used a multi-socket box (in case
some cache coherency effect was not occurring on my development
laptops).  I did learn some interesting things about parallel query
performance that I plan to follow up on, but I had no luck in
reproducing this error.  Rats.

One observation is that the other report involved a fairly simple
Parallel Hash Join query (on 11), and this report involves Parallel
Index Scan and Parallel Bitmap Index Scan (on 10), so that suggests
that it's probably not a bug in the parallel executor code (for
example an access-after-free, whose undefined behaviour could in
theory look like this with unlucky timing, I speculate) but rather
something lower level.

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


Commits

  1. Fix race in dsm_attach() when handles are reused.