Re: BUG #15290: Stuck Parallel Index Scan query
От
Andres Freund
Тема
Re: BUG #15290: Stuck Parallel Index Scan query
Дата
Msg-id
20180723043544.xg2yvsj6r6b2yuhb@alap3.anarazel.de
Ответ на
Re: BUG #15290: Stuck Parallel Index Scan query (Thomas Munro)
Список
Дерево обсуждения
BUG #15290: Stuck Parallel Index Scan query PG Bug reporting form <noreply@postgresql.org>
Re: BUG #15290: Stuck Parallel Index Scan query Victor Yegorov <vyegorov@gmail.com>
Re: BUG #15290: Stuck Parallel Index Scan query Victor Yegorov <vyegorov@gmail.com>
Re: BUG #15290: Stuck Parallel Index Scan query Thomas Munro <thomas.munro@enterprisedb.com>
Re: BUG #15290: Stuck Parallel Index Scan query Andres Freund <andres@anarazel.de>
Re: BUG #15290: Stuck Parallel Index Scan query Victor Yegorov <vyegorov@gmail.com>
Re: BUG #15290: Stuck Parallel Index Scan query Thomas Munro <thomas.munro@enterprisedb.com>
Re: BUG #15290: Stuck Parallel Index Scan query Victor Yegorov <vyegorov@gmail.com>
Re: BUG #15290: Stuck Parallel Index Scan query Thomas Munro <thomas.munro@enterprisedb.com>
Re: BUG #15290: Stuck Parallel Index Scan query Andres Freund <andres@anarazel.de>
Re: BUG #15290: Stuck Parallel Index Scan query Thomas Munro <thomas.munro@enterprisedb.com>
Re: BUG #15290: Stuck Parallel Index Scan query Amit Kapila <amit.kapila16@gmail.com>
Re: BUG #15290: Stuck Parallel Index Scan query Amit Kapila <amit.kapila16@gmail.com>
Re: BUG #15290: Stuck Parallel Index Scan query Thomas Munro <thomas.munro@enterprisedb.com>
Re: BUG #15290: Stuck Parallel Index Scan query Victor Yegorov <vyegorov@gmail.com>
Re: BUG #15290: Stuck Parallel Index Scan query Amit Kapila <amit.kapila16@gmail.com>
On 2018-07-23 16:30:28 +1200, Thomas Munro wrote: > TerminateBackgroundWorker() sets a shm flag and signals the > postmaster, the postmaster signals the worker with SIGTERM, the worker > handles SIGTERM in die() by setting ProcDiePending = true, > InterruptPending= true and then setting its own latch, and the > ConditionVarableSleep() loop should wake up, go around its loop again > and run CHECK_FOR_INTERRUPTS() which sees InterruptPending and runs > ProcessInterrupts(), which sees ProcDiePending and reports FATAL. So > which domino fell short here? I've not looked at this, but is it possible that interrupts aren't accepted because they're held (e.g. because of an lwlock)? Greetings, Andres Freund
В списке pgsql-bugs по дате отправления