RE: BUG #14891: Old cancel request presented by pgbouncer honoredafter skipping a query.
От | Skarsol |
---|---|
Тема | RE: BUG #14891: Old cancel request presented by pgbouncer honoredafter skipping a query. |
Дата | |
Msg-id | c743450b21e3984a13680b879c5048ef@wurm.cx обсуждение исходный текст |
Ответы |
Re: BUG #14891: Old cancel request presented by pgbouncer honoredafter skipping a query.
|
Список | pgsql-bugs |
Well, taking pgbouncer down to a 60 second connection lifetime was insufficient to completely alleviate this. We had another transaction get killed yesterday due to a different query being cancelled. I'm still unsure how this isn't affecting other people. At this point, we're going to change our application to just abandon the current postgres connection when a user hits cancel instead of actually sending the cancel request. Ugly hack, but I'm not sure what else to do at this point. I'm still open to suggestions though. Or really, any discussion about this issue at all. Would this belong better on a different list? ----- The following bug has been logged on the website: Bug reference: 14891 Logged by: Skarsol Email address: postgresql(at)skarsol(dot)com PostgreSQL version: 9.6.3 Operating system: Linux 4.4.8-hardened-r1 #4 SMP Mon Jun 12 Description: This might be a symptom of the issue discussed in the ToDo "Changes to make cancellations more reliable and more secure" but as it is related to the pgbouncer bug I've opened at https://github.com/pgbouncer/pgbouncer/issues/245 I figured I'd post it over here just to make sure. As the last step of this bug, pgbouncer 1.7.2 presents a cancel request to postgres 9.6.3. This request targets pid 29330 which is connected to pgbouncer on port 33024. That pid then accepts a new query, returns a result set, accepts another new query, and then cancels that one out. Expected behavior would have been for either no cancel (as that pid was between queries at the time) or to cancel the first query. Cancelling the 2nd query is just weird (to me). I have no idea how much of this is related to whatever pgbouncer is doing to delay the cancel in the first place before presenting it to postgres. I'm aware that we're 2 minor versions behind, but I don't see anything that seems relevant to this in the changelogs. Image of the relevant wireshark display at https://user-images.githubusercontent.com/1915152/32578433-d5d4a71c-c4a2-11e7-9d25-f59d5afbb06b.jpg
В списке pgsql-bugs по дате отправления: