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
-
Fix race in dsm_attach() when handles are reused.
- 6c0fb9418925 12.0 landed
- bd195071fd2b 9.4.22 landed
- b7c8766d3480 9.5.17 landed
- cb0680573f7b 9.6.13 landed
- cb3d674e1709 10.8 landed
- faf132449c0c 11.3 landed