Re: Replication server timeout patch
От | Fujii Masao |
---|---|
Тема | Re: Replication server timeout patch |
Дата | |
Msg-id | AANLkTikb7=mOhP2evnJ5sm6znarwE3J3xyrWWhJmLC4g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Replication server timeout patch (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Replication server timeout patch
Re: Replication server timeout patch |
Список | pgsql-hackers |
On Mon, Mar 28, 2011 at 7:49 PM, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: >> pq_flush_if_writable() calls internal_flush() without using PG_TRY block. >> This seems unsafe because for example pgwin32_waitforsinglesocket() >> called by secure_write() can throw ERROR. > > Perhaps it's time to give up on the assumption that the socket is in > blocking mode except within those two functions. Attached patch adds the > pq_set_nonblocking() function from your patch, and adds calls to it before > all secure_read/write operations to put the socket in the right mode. > There's only a few of those operations. Sounds good. + pq_set_nonblocking(false); /* XXX: Is this required? */ No. Since secure_close and close_SSL don't use MyProcPort->sock and MyProcPort->noblock which can be changed in pq_set_nonblocking, I don't think that is required. + pq_putmessage_noblock('d', msgbuf, 1 + sizeof(WalDataMessageHeader) + nbytes); Don't we need to check the return value of pq_putmessage_noblock? That can return EOF when trouble happens (for example the send system call fails). > Should we use COMMERROR instead of ERROR if we fail to put the socket in the > right mode? Maybe. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: