Re: Race conditions in 019_replslot_limit.pl - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Race conditions in 019_replslot_limit.pl
Date
Msg-id 4165799.1645226121@sss.pgh.pa.us
Whole thread Raw
In response to Re: Race conditions in 019_replslot_limit.pl  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2022-02-17 21:55:21 -0800, Andres Freund wrote:
>> Isn't it pretty bonkers that we allow error processing to get stuck behind
>> network traffic, *before* we have have released resources (locks etc)?

It's more or less intentional, per elog.c:

    /*
     * This flush is normally not necessary, since postgres.c will flush out
     * waiting data when control returns to the main loop. But it seems best
     * to leave it here, so that the client has some clue what happened if the
     * backend dies before getting back to the main loop ... error/notice
     * messages should not be a performance-critical path anyway, so an extra
     * flush won't hurt much ...
     */
    pq_flush();

Perhaps it'd be sensible to do this only in debugging (ie Assert)
builds?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Time to drop plpython2?
Next
From: Michael Paquier
Date:
Subject: Re: shared_preload_libraries = 'pg_stat_statements' failing with installcheck (compute_query_id = auto)