Re: Streaming replication and non-blocking I/O
От | Fujii Masao |
---|---|
Тема | Re: Streaming replication and non-blocking I/O |
Дата | |
Msg-id | 3f0b79eb1001140102n10fdf409id404c6d656aa245b@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Streaming replication and non-blocking I/O (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Streaming replication and non-blocking I/O
|
Список | pgsql-hackers |
On Wed, Jan 13, 2010 at 7:27 PM, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: > the frontend always puts the > connection to non-blocking mode, while the backend uses blocking mode. Really? By default (i.e., without the expressly setting by using PQsetnonblocking()), the connection is set to blocking mode even in frontend. Am I missing something? > At least with SSL, I think it's possible for pq_wait() to return false > positives, if the SSL layer decides to renegotiate the connection > causing data to flow in the other direction in the underlying TCP > connection. A false positive would lead cause walsender to block > indefinitely on the pq_getbyte() call. Sorry. I could not understand that issue scenario. Could you explain it in more detail? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: