Re: BUG #15585: infinite DynamicSharedMemoryControlLock waiting inparallel query
От | Thomas Munro |
---|---|
Тема | Re: BUG #15585: infinite DynamicSharedMemoryControlLock waiting inparallel query |
Дата | |
Msg-id | CAEepm=3AqfdELjsKzzik8vYBnSHBFSWAmuxWGV2HNiOgVsX22g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #15585: infinite DynamicSharedMemoryControlLock waiting inparallel query (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: BUG #15585: infinite DynamicSharedMemoryControlLock waiting inparallel query
|
Список | 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
В списке pgsql-bugs по дате отправления: