Re: Cancelling parallel query leads to segfault - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Cancelling parallel query leads to segfault
Date
Msg-id 888e2e27-f88f-56f8-76a7-925ef7b114c3@2ndquadrant.com
Whole thread Raw
In response to Re: Cancelling parallel query leads to segfault  (Andres Freund <andres@anarazel.de>)
Responses Re: Cancelling parallel query leads to segfault  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 2/6/18 12:06, Andres Freund wrote:
> On 2018-02-06 12:01:08 -0500, Peter Eisentraut wrote:
>> On 2/1/18 20:35, Andres Freund wrote:
>>> On February 1, 2018 11:13:06 PM GMT+01:00, Peter Eisentraut
>>> <peter.eisentraut@2ndquadrant.com> wrote:
>>>> Here is a patch to implement that idea. Do you have a way to test it
>>>> repeatedly, or do you just randomly cancel queries?
>>>
>>> For me cancelling the long running parallel queries I tried reliably
>>> triggers the issue. I encountered it while cancelling tpch q1 during JIT
>>> work.
>>
>> Why does canceling a query result in elog(FATAL)?  It should just be
>> elog(ERROR), which wouldn't trigger this issue.
> 
> The workers are shut down.

I have used the setup mentioned in
<https://www.postgresql.org/message-id/6a909374-2602-7136-8c70-397330a418f3%402ndquadrant.com>
to reproduce this, without success.  I have tried statement_timeout and
manual cancels.  Any other ideas?

I don't doubt that the issue exists, but it would be nice to be able to
reproduce it.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: rename sgml files?
Next
From: Tom Lane
Date:
Subject: Re: rename sgml files?