Re: NOTIFY does not work as expected
От | Andres Freund |
---|---|
Тема | Re: NOTIFY does not work as expected |
Дата | |
Msg-id | 20181018224608.6d4v2fadyu3vrbx2@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: NOTIFY does not work as expected (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: NOTIFY does not work as expected
|
Список | pgsql-bugs |
On 2018-10-18 18:39:34 -0400, Tom Lane wrote: > Nope :-(. However, I got around to looking at this problem, and I concur > with Jeff's diagnosis: the code around ProcessClientReadInterrupt is > buggy because it does not account for the possibility that the process > latch was cleared some time ago while unhandled interrupt-pending flags > remain set. There are some other issues too: > > 1. ProcessClientWriteInterrupt has the same problem. > > 2. I don't believe the "blocked" vs "not-blocked" distinction one bit. > At best, it creates race-condition-like changes in behavior depending > on exactly when a signal arrives vs when data arrives or is sent. > At worst, I think it creates the same problem it's purporting to solve, > ie failure to respond to ProcDiePending at all. I think the > before/during/after calls to ProcessClientXXXInterrupt should just all > behave the same and always be willing to execute ProcDiePending. That distinction was introduced because people (IIRC you actually) were worried that we'd be less likely to get error messages out to the client. Especially when you check unconditionally before actually doing the write, it's going to be far less likely that we are able to send something out to the client. Greetings, Andres Freund
В списке pgsql-bugs по дате отправления: