Re: Queries that should be canceled will get stuck on secure_write function
От | Andres Freund |
---|---|
Тема | Re: Queries that should be canceled will get stuck on secure_write function |
Дата | |
Msg-id | b209a5d7-f7ef-4272-9fd2-111495f8bfc4@www.fastmail.com обсуждение исходный текст |
Ответ на | Re: Queries that should be canceled will get stuck on secure_write function (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Queries that should be canceled will get stuck on secure_write function
|
Список | pgsql-hackers |
Hi, On Fri, Aug 27, 2021, at 13:07, Robert Haas wrote: > On Fri, Aug 27, 2021 at 3:24 PM Andres Freund <andres@anarazel.de> wrote: > > I wonder if we could improve the situation somewhat by using the non-blocking > > pqcomm functions in a few select places. E.g. if elog.c's > > send_message_to_frontend() sent its message via a new pq_endmessage_noblock() > > (which'd use the existing pq_putmessage_noblock()) and used > > pq_flush_if_writable() instead of pq_flush(), we'd a) not block sending to the > > client before AbortCurrentTransaction(), b) able to queue further error > > messages safely. > > pq_flush_if_writable() could succeed in sending only part of the data, > so I don't see how this works. All the data is buffered though, so I don't see that problem that causes? Andres
В списке pgsql-hackers по дате отправления: