From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | sk(at)zsrv(dot)org, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #15585: infinite DynamicSharedMemoryControlLock waiting in parallel query |
Date: | 2019-01-11 05:16:27 |
Message-ID: | CAEepm=3AqfdELjsKzzik8vYBnSHBFSWAmuxWGV2HNiOgVsX22g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, Jan 11, 2019 at 10:04 AM Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2019-01-11 08:36:35 | BUG #15589: Due to missing wal, restore ends prematurely and opens database for read/write |
Previous Message | AP | 2019-01-11 04:35:03 | Re: BUG #15582: ALTER TABLE/INDEX ... SET TABLESPACE does not free disk space |