Re: pgsql: Replace PostmasterRandom() with a stronger source, second attemp - Mailing list pgsql-committers

From Michael Paquier
Subject Re: pgsql: Replace PostmasterRandom() with a stronger source, second attemp
Date
Msg-id CAB7nPqQ3FMg=OUZM99PNtpZgQLxGEHPbStJ2f7X-xdOAtZAonQ@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Replace PostmasterRandom() with a stronger source, second attemp  (Andres Freund <andres@anarazel.de>)
Responses Re: pgsql: Replace PostmasterRandom() with a stronger source, second attemp
List pgsql-committers
On Wed, Dec 7, 2016 at 7:46 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2016-12-05 11:44:37 +0000, Heikki Linnakangas wrote:
>> Replace PostmasterRandom() with a stronger source, second attempt.
>
> Since this went in I've seen
> 2016-12-06 14:42:17.005 PST [23658][] LOG:  wrong key in cancel request for process 23657
> 2016-12-06 14:42:19.010 PST [23662][] LOG:  wrong key in cancel request for process 23657
> a couple times.
>
> I've not yet started debugging it. But it seems to only happen in the
> first (few?) queries in a new connection.

Hm. I recall testing this patch if cancel keys are working or not, but
connecting with pgbench -C runnung in parallel I am seeing the
following spurious error:
=# select pg_sleep(10);
^CCancel request sent
Time: 10001.496 ms (00:10.001)

With the logs complaining as well:
[1-1] db=[unknown],user=[unknown],app=[unknown],client=[local] LOG:
wrong key in cancel request for process 57361

As far as I can see processCancelRequest uses a long variable, and it
gets compared with an int32. MyCancelKey has been changed to an int32
in globals.c with the above commit. So on 64b machines the current
code is aimed to fail. Attached is a patch to fix the issue.

It is taking me at most 10 times to reproduce the failure without the
patch, after trying 20~ times with the patch I am still able to cancel
the queries.
--
Michael

Attachment

pgsql-committers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: pgsql: Replace PostmasterRandom() with a stronger source, second attemp
Next
From: Tom Lane
Date:
Subject: pgsql: Put AC_MSG_RESULT() call in the right place.