Re: Escaping from blocked send() reprised.

Hello, The replies follow are mainly as a memo for myself so
please don't be bothered to answer until the time comes.

At Mon, 30 Jun 2014 11:27:47 -0400, Robert Haas <robertmhaas(at)gmail(dot)com> wrote in <CA+TgmoZfcGzAEmtbyoCe6VdHnq085x+ox752zuJ2AKN=Wc8PnQ(at)mail(dot)gmail(dot)com>
> You should probably add your patch here, so it doesn't get forgotten about:
>
> https://commitfest.postgresql.org/action/commitfest_view/open

Ok, I'll put this there.

> We're focused on reviewing patches for the current CommitFest, so your
> patch might not get attention right away. A couple of general
> thoughts on this topic:

Thank you for suggestions. I'll consider on them.

> 1. I think it's the case that there are platforms around where a
> signal won't cause send() to return EINTR.... and I'd be entirely
> unsurprised if SSL_write() doesn't necessarily return EINTR in that
> case. I'm not sure what, if anything, we can do about that.

man 2 send on FreeBSD has not description about EINTR.. And even
on linux, send won't return EINTR for most cases, at least I
haven't seen that. So send()=-1,EINTR seems to me as only an
equivalent of send() = 0. I have no idea about what the
implementer thought the difference is.

> 2. I think it would be reasonable to try to kill off the connection
> without notifying the client if we're unable to send the data to the
> client in a reasonable period of time. But I'm unsure what "a
> reasonable period of time" means. This patch would basically do it
> after no delay at all, which seems like it might be too aggressive.
> However, I'm not sure.

I think there's no such a reasonable time. The behavior might
should be determined from another point.. On alternative would be
let pg_terminate_backend() have a parameter instructing force
shutodwn (how to propagate it?), or make a forced shutdown on
duplicate invocation of pg_terminate_backend().

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center