Re: Escaping from blocked send() reprised.

On Sat, Jan 10, 2015 at 03:25:42AM +0100, Andres Freund wrote:
> 0001-Allow-latches-to-wait-for-socket-writability-without.patch
> Imo pretty close to commit and can be committed independently.

The key open question is whether all platforms of interest can reliably detect
end-of-file when poll()ing or select()ing for write only. Older GNU/Linux
select() cannot; see attached test program. We use poll() there anyway, so
the bug in that configuration does not affect PostgreSQL. Is it a bellwether
of similar bugs in other implementations, bugs that will affect PostgreSQL?

> This previously had explicitly been forbidden in e42a21b9e6c9, as
> there was no use case at that point. We now are looking into making
> FE/BE communication use latches, so it

Truncated sentence.

> + if (pfds[0].revents & (POLLHUP | POLLERR | POLLNVAL))
> + {
> + /* EOF/error condition */
> + if (wakeEvents & WL_SOCKET_READABLE)
> + result |= WL_SOCKET_READABLE;
> + if (wakeEvents & WL_SOCKET_WRITEABLE)
> + result |= WL_SOCKET_WRITEABLE;
> + }

With some poll() implementations (e.g. OS X), this can wrongly report
WL_SOCKET_WRITEABLE if the peer used shutdown(SHUT_WR). I tentatively think
that's acceptable. libpq does not use shutdown(), and other client interfaces
would do so at their own risk. Should we worry about hostile clients creating
a denial-of-service by causing a server send() to block unexpectedly?
Probably not; a user able to send arbitrary TCP traffic to the postmaster port
can already achieve that.

> + if (resEvents.lNetworkEvents & FD_CLOSE)
> + {
> + if (wakeEvents & WL_SOCKET_READABLE)
> + result |= WL_SOCKET_READABLE;
> + if (wakeEvents & WL_SOCKET_WRITEABLE)
> + result |= WL_SOCKET_WRITEABLE;
> + }
> +
> }

Extra blank line.