Re: Queries that should be canceled will get stuck on secure_write function - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Queries that should be canceled will get stuck on secure_write function
Date
Msg-id b209a5d7-f7ef-4272-9fd2-111495f8bfc4@www.fastmail.com
Whole thread Raw
In response to Re: Queries that should be canceled will get stuck on secure_write function  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Queries that should be canceled will get stuck on secure_write function  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Queries that should be canceled will get stuck on secure_write function
Next
From: "Bossart, Nathan"
Date:
Subject: Re: Estimating HugePages Requirements?