Re: Race conditions in 019_replslot_limit.pl
От | Tom Lane |
---|---|
Тема | Re: Race conditions in 019_replslot_limit.pl |
Дата | |
Msg-id | 4168596.1645228154@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Race conditions in 019_replslot_limit.pl (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > On 2022-02-18 18:15:21 -0500, Tom Lane wrote: >> Perhaps it'd be sensible to do this only in debugging (ie Assert) >> builds? > That seems not great, because it pretty clearly can lead to hangs, which is > problematic in tests too. What about using pq_flush_if_writable()? In nearly > all situations that'd still push the failure to the client. That'd be okay by me. > We'd also need to add pq_endmessage_noblock(), because the pq_endmessage() > obviously tries to send (as in the backtrace upthread) if the output buffer is > large enough, which it often will be in walsender. I don't see that as "obvious". If we're there, we do not have an error situation. > I guess we could try to flush in a blocking manner sometime later in the > shutdown sequence, after we've released resources? But I'm doubtful it's a > good idea, we don't really want to block waiting to exit when e.g. the network > connection is dead without the TCP stack knowing. I think you are trying to move in the direction of possibly exiting without ever sending at all, which does NOT seem like an improvement. regards, tom lane
В списке pgsql-hackers по дате отправления: