Re: Race conditions with checkpointer and shutdown
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Michael Paquier <michael@paquier.xyz>,
Thomas Munro <thomas.munro@gmail.com>,
Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-04-29T16:55:31Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.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
Commits
-
In walreceiver, don't try to do ereport() in a signal handler.
- ac8f2e1ef34f 10.9 landed
- 9346d396fd4a 11.4 landed
- a1a789eb5ac8 12.0 landed