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

From Robert Haas
Subject Re: Queries that should be canceled will get stuck on secure_write function
Date
Msg-id CA+TgmoZD30=mmmxyYqA-XNJzd51bCESDAz38iCg3MEsGnx1vGw@mail.gmail.com
Whole thread Raw
In response to Re: Queries that should be canceled will get stuck on secure_write function  (Andres Freund <andres@anarazel.de>)
Responses Re: Queries that should be canceled will get stuck on secure_write function  ("Andres Freund" <andres@anarazel.de>)
List pgsql-hackers
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.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: log_autovacuum in Postgres 14 -- ordering issue
Next
From: "Andres Freund"
Date:
Subject: Re: Queries that should be canceled will get stuck on secure_write function