From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Cancelling parallel query leads to segfault |
Date: | 2018-02-12 20:43:49 |
Message-ID: | 888e2e27-f88f-56f8-76a7-925ef7b114c3@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(dot)eisentraut(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-02-12 21:19:48 | Re: rename sgml files? |
Previous Message | Peter Eisentraut | 2018-02-12 20:30:26 | rename sgml files? |