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 по дате отправления: