On Mon, Jul 23, 2018 at 8:52 AM, Victor Yegorov <vyegorov@gmail.com> wrote:
> вс, 22 июл. 2018 г. в 21:31, PG Bug reporting form <noreply@postgresql.org>:
>>
>> The following bug has been logged on the website:
>>
>> Bug reference: 15290
>> Logged by: Victor Yegorov
>> Email address: vyegorov@gmail.com
>> PostgreSQL version: 10.4
>> Operating system: Debian GNU/Linux 8.7 (jessie)
Thanks for the detailed report! To summarise your back traces, we have:
PID 2877 is the master process and has decided to abort and is waiting
for the workers to exit:
WaitLatch
WaitForBackgroundWorkerShutdown
WaitForParallelWorkersToExit
DestroyParallelContext
AtEOXact_Parallel
AbortTransaction
AbortCurrentTransaction
PostgresMain
PIDs 3416, 3417, 3418, 3419 meanwhile are waiting to seize the scan head:
WaitEventSetWaitBlock
ConditionVariableSleep
_bt_parallel_seize
_bt_readnextpage
Presumably 2877 has it (?), but aborted (do you have an error message
in the server log?), and the workers have somehow survived
TerminateBackgroundWorker() (called by DestroyParallelContext()).
Hmm.
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?
--
Thomas Munro
http://www.enterprisedb.com