| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Race conditions with checkpointer and shutdown |
| Date: | 2019-04-29 16:55:31 |
| Message-ID: | 28349.1556556931@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-04-27 20:56:51 -0400, Tom Lane wrote:
>> The existing code does not use PQsetnonblocking, which means that it's
>> theoretically at risk of blocking while pushing out data to the remote
>> server. In practice I think that risk is negligible because (IIUC) we
>> don't send very large amounts of data at one time. So I didn't bother to
>> change that. Note that for the most part, if that happened, the existing
>> code was at risk of slow response to SIGTERM anyway since it didn't have
>> Enable/DisableWalRcvImmediateExit around the places that send data.
> Hm, I'm not convinced that's OK. What if there's a network hickup? We'll
> wait until there's an OS tcp timeout, no?
No. send() is only going to block if there's no room in the kernel's
buffers, and that would only happen if we send a lot of data in between
waits to receive data. Which, AFAIK, the walreceiver never does.
We might possibly need to improve that code in the future, but I don't
think there's a need for it today.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2019-04-29 17:04:30 | Re: Race conditions with checkpointer and shutdown |
| Previous Message | Rob | 2019-04-29 16:40:01 | CHAR vs NVARCHAR vs TEXT performance |