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 <robertmh...@gmail.com> wrote in <CA+TgmoZfcGzAEmtbyoCe6VdHnq085x+ox752zuJ2AKN=wc8...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
