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)