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@gmail.com> wrote in
<CA+TgmoZfcGzAEmtbyoCe6VdHnq085x+ox752zuJ2AKN=Wc8PnQ@mail.gmail.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