From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ACK from walreceiver to walsender |
Date: | 2010-01-08 12:44:11 |
Message-ID: | 3f0b79eb1001080444gc379087q88b844d81bdffb42@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 8, 2010 at 6:39 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> There's no guarantee walreceiver will read the 'X' before trying to
> write() to the socket, so we can't rely on that to determine whether to
> suppress the "could not send data to client" message.
s/walreceiver/walsender?
> We could try to read() from the socket after the write() has failed, to
> see if there's an 'X' message pending. Not sure it's worth it. I think
> we would have to put the socket into non-blocking mode before the
> read(), to avoid blocking if the write() failed for some other reason.
> Or select() to see if there's incoming data. I'm inclined to just not
> bother..
Umm.. if no action is taken, walsender process would remain until
it tries to write to the socket in that case. Is this OK? I think that this
is more problematic rather than output of the "could not send data
to client" message.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Tim Bunce | 2010-01-08 12:46:13 | Initial refactoring of plperl.c - updated |
Previous Message | Simon Riggs | 2010-01-08 12:36:00 | Re: 8.5alpha3 hot standby crash report (DatabasePath related?) |