Re: Query cancel seems to be broken in master since Oct 17

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Query cancel seems to be broken in master since Oct 17
Date: 2016-10-18 13:31:00
Message-ID: 3c3f224d-d7c4-30af-b3b9-d77a0525ba44@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/18/2016 04:13 PM, Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On Tue, Oct 18, 2016 at 1:00 AM, Vladimir Sitnikov <
>> sitnikov(dot)vladimir(at)gmail(dot)com> wrote:
>>> The test executes "select pg_sleep(10)" and tries to cancel it. In recent
>>> master builds, cancel seems to be ignored, and the statement lasts for 10
>>> seconds.
>
>> My guess is it's related to this:
>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=9e083fd4683294f41544e6d0d72f6e258ff3a77c
>> That's certainly not intended to break things, but that was changed on Oct
>> 17 and it relates to cancel keys.
>> What platform does the postgres server run on? Can can you check if query
>> cancel works on libpq or if it's completely broken?
>
> I can confirm that query cancel is broken in HEAD on RHEL6.
>
> regression=# select pg_sleep(10);
> ^CCancel request sent
> ... nothing happens for the balance of the 10 seconds ...
> regression=#
>
> There's a smoking gun in the postmaster log:
>
> 2016-10-18 09:10:34.547 EDT [18502] LOG: wrong key in cancel request for process 18491

Ok, I've reverted that commit for now. It clearly needs more thought,
because of this, and the pademelon failure discussed on the other thread.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2016-10-18 13:45:55 Re: emergency outage requiring database restart
Previous Message Andreas Joseph Krogh 2016-10-18 13:13:58 Move pg_largeobject to a different tablespace *without* turning on system_table_mods.