Re: Escaping from blocked send() reprised.
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
From: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
To: hlinnakangas@vmware.com
Cc: robertmhaas@gmail.com, pgsql-hackers@postgresql.org
Date: 2014-08-28T12:47:04Z
Lists: pgsql-hackers
Attachments
- 0001_Revise_socket_emulation_for_win32_backend.patch (text/x-patch) patch
- 0002_Allow_backend_termination_during_write_blocking.patch (text/x-patch) patch
Hello, sorry for the dazed reply in the previous mail. I made revised patch for this issue. Attached patches are following, - 0001_Revise_socket_emulation_for_win32_backend.patch Revises socket emulation on win32 backend so that each socket can have its own blocking mode state. - 0002_Allow_backend_termination_during_write_blocking.patch The patch to solve the issue. This patch depends on the 0001_ patch. ========== > > I'm marking this as Waiting on Author in the commitfest app, because: > > 1. the protocol violation needs to be avoided one way or another, and > > 2. the behavior needs to be consistent so that a single > > pg_terminate_backend() is enough to always kill the connection. - Preventing protocol violation. To prevent protocol violation, secure_write sets ClientConnectionLost when SIGTERM detected, then internal_flush() and ProcessInterrupts() follow the instruction. - Single pg_terminate_backend surely kills the backend. secure_raw_write() uses non-blocking socket and a loop of select() with timeout to surely detects received signal(SIGTERM). To avoid frequent switching of blocking mode, the bare socket for Port is put to non-blocking mode from the first in StreamConnection() and blocking mode is controlled only by Port->noblock in secure_raw_read/write(). To make the code mentioned above (Patch 0002) tidy, rewrite the socket emulation code for win32 backends so that each socket can have its own non-blocking state. (patch 0001) Some concern about this patch, - This patch allows the number of non-blocking socket to be below 64 (FD_SETSIZE) on win32 backend but it seems to be sufficient. - This patch introduced redundant socket emulation for win32 backend but win32 bare socket for Port is already nonblocking as described so it donsn't seem to be a serious problem on performance. Addition to it, since I don't know the reason why win32/socket.c provides the blocking-mode socket emulation, I decided to preserve win32/socket.c to have blocking socket emulation. Possibly it can be removed. Any suggestions? regards, -- Kyotaro Horiguchi NTT Open Source Software Center
Commits
-
Assert that WaitLatchOrSocket callers cannot wait only for writability.
- e42a21b9e6c9 9.2.0 cited