Re: pgsql: Replace PostmasterRandom() with a stronger source, second attemp

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: pgsql: Replace PostmasterRandom() with a stronger source, second attemp
Дата
Msg-id CAB7nPqQ3FMg=OUZM99PNtpZgQLxGEHPbStJ2f7X-xdOAtZAonQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pgsql: Replace PostmasterRandom() with a stronger source, second attemp  (Andres Freund <andres@anarazel.de>)
Ответы Re: pgsql: Replace PostmasterRandom() with a stronger source, second attemp
Список 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

Вложения

В списке pgsql-committers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: pgsql: Replace PostmasterRandom() with a stronger source, second attemp
Следующее
От: Tom Lane
Дата:
Сообщение: pgsql: Put AC_MSG_RESULT() call in the right place.