Re: Disconnect if socket cannot be put into non-blocking mode

On 11/03/2024 16:44, Heikki Linnakangas wrote:
> While self-reviewing my "Refactoring backend fork+exec code" patches, I
> noticed this in pq_init():
> 
>> 	/*
>> 	 * In backends (as soon as forked) we operate the underlying socket in
>> 	 * nonblocking mode and use latches to implement blocking semantics if
>> 	 * needed. That allows us to provide safely interruptible reads and
>> 	 * writes.
>> 	 *
>> 	 * Use COMMERROR on failure, because ERROR would try to send the error to
>> 	 * the client, which might require changing the mode again, leading to
>> 	 * infinite recursion.
>> 	 */
>> #ifndef WIN32
>> 	if (!pg_set_noblock(MyProcPort->sock))
>> 		ereport(COMMERROR,
>> 				(errmsg("could not set socket to nonblocking mode: %m")));
>> #endif
>>
>> #ifndef WIN32
>>
>> 	/* Don't give the socket to any subprograms we execute. */
>> 	if (fcntl(MyProcPort->sock, F_SETFD, FD_CLOEXEC) < 0)
>> 		elog(FATAL, "fcntl(F_SETFD) failed on socket: %m");
>> #endif
> 
> Using COMMERROR here seems bogus. Firstly, if there was a problem with
> recursion, surely the elog(FATAL) that follows would also be wrong. But
> more seriously, it's not cool to continue using the connection as if
> everything is OK, if we fail to put it into non-blocking mode. We should
> disconnect. (COMMERROR merely logs the error, it does not bail out like
> ERROR does)
> 
> Barring objections, I'll commit and backpatch the attached to fix that.

Committed.

-- 
Heikki Linnakangas
Neon (https://neon.tech)