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.