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

Hi

> I think the root cause is earlier and in a different process (see
> ProcessInterrupt() in the stack). Presumably one that reported
> "dsa_area could not attach to segment" is closer to the point where
> things go wrong.

I agree.
Log was:
2019-01-23 20:31:33.508 UTC 2593 @ from [vxid:121/1810816 txid:0] [] ERROR: dsa_area could not attach to segment
2019-01-23 20:31:33.508 UTC 2593 @ from [vxid:121/1810816 txid:0] [] STATEMENT: SELECT ...
2019-01-23 20:31:33.510 UTC 22941 @ from [vxid: txid:0] [] LOG: worker process: parallel worker for PID 31224 (PID 2593) exited with exit code 1
2019-01-23 20:31:33.511 UTC 31224 user(at)db from 127.0.0.1 [vxid:20/25544096 txid:0] [SELECT] ERROR: dsa_area could not attach to segment
2019-01-23 20:31:33.511 UTC 31224 user(at)db from 127.0.0.1 [vxid:20/25544096 txid:0] [SELECT] STATEMENT: SELECT ...
2019-01-23 20:31:33.511 UTC 2595 @ from [vxid:138/277023 txid:0] [] FATAL: terminating connection due to administrator command
2019-01-23 20:31:33.511 UTC 2595 @ from [vxid:138/277023 txid:0] [] STATEMENT: SELECT ...
2019-01-23 20:31:33.511 UTC 2594 @ from [vxid:136/536348 txid:0] [] ERROR: dsa_area could not attach to segment
2019-01-23 20:31:33.511 UTC 2594 @ from [vxid:136/536348 txid:0] [] STATEMENT: SELECT ...
2019-01-23 20:31:33.512 UTC 2595 @ from [vxid:138/0 txid:0] [] FATAL: cannot unpin a segment that is not pinned
2019-01-23 20:31:33.513 UTC 22941 @ from [vxid: txid:0] [] LOG: worker process: parallel worker for PID 31224 (PID 2594) exited with exit code 1

22941 postmaster, 31224 - parallel leader, 2595 - parallel worker (backtrace was from this process), 2593 and 2594 seems another parallel workers for this query.

But I was surprised by possible double call dsm_backend_shutdown. Can first process (2593 in my case) be terminated with some reason (and therefore call shmem_exit) but be logged only with second error?

> If you are in a position to reproduce this

Unfortunally no, i can not run this database with modified source. And i still can not reproduce this bug by hand. Modified source was runned on my local host few days long. Without some luck...

regards, Sergei