Re: walreceiver is uninterruptible on win32
От | Magnus Hagander |
---|---|
Тема | Re: walreceiver is uninterruptible on win32 |
Дата | |
Msg-id | 9837222c1003150242p7733c7c6je440d528f04b3a01@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: walreceiver is uninterruptible on win32 (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: walreceiver is uninterruptible on win32
(Fujii Masao <masao.fujii@gmail.com>)
Re: walreceiver is uninterruptible on win32 (Joe Conway <mail@joeconway.com>) |
Список | pgsql-hackers |
On Mon, Mar 15, 2010 at 10:14, Fujii Masao <masao.fujii@gmail.com> wrote: > On Fri, Mar 12, 2010 at 8:13 PM, Magnus Hagander <magnus@hagander.net> wrote: >> On Wed, Mar 10, 2010 at 10:09, Fujii Masao <masao.fujii@gmail.com> wrote: >>> Hi, >>> >>> http://archives.postgresql.org/pgsql-hackers/2010-01/msg01672.php >>> On win32, the blocking libpq functions like PQconnectdb() and >>> PQexec() are uninterruptible since they use the vanilla select() >>> instead of our signal emulation layer compatible select(). >>> Nevertheless, currently walreceiver uses them to establish a >>> connection, send a handshake message and wait for the reply. >>> So walreceiver also becomes uninterruptible for a while. This >>> is the must-fix problem for 9.0. >>> >>> I replaced the blocking libpq functions currently used with >>> asynchronous ones, and used the emulated version of select() >>> to wait, to make walreceiver interruptible. Here is the patch. >> >> These are issues that affect other things running libpq in the backend >> as well, right? Such as dblink? > > Yes. So Heikki wrote the patch for dblink. > http://archives.postgresql.org/pgsql-hackers/2010-01/msg02072.php IIRC that was never applied. > >> Perhaps we can factor out most of this >> into functions in backend/port/win32 so that we can re-use it fro >> there? > > Sorry. I couldn't get your point. Could you explain it in detail? What I'm referring to is the part that Heikki writes as "The implementation should be shared between the two, but I'm not sure how". I think we should try to factor out things that can be shared into separate functions and stick those in port/win32 (assuming they're win32-specific, otherwise, in another suitable location), and then call them from both. There seems to be a lot of things that should be doable that way. I notice for example that the dblink patch doesn't have the code for timeout handling - shouldn't it? I think we need to look at this as a single problem needing to be solved, and then have the same solution applied to dblink and walreceiver. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: