Re: ACK from walreceiver to walsender - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: ACK from walreceiver to walsender
Date
Msg-id 4B46FD5A.8060609@enterprisedb.com
Whole thread Raw
In response to Re: ACK from walreceiver to walsender  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: ACK from walreceiver to walsender  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
Fujii Masao wrote:
> On Fri, Jan 8, 2010 at 5:55 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> I don't think we need to treat 'X' differently from EOF. You get an
>> error anyway if the write() fails. That's actually a bit annoying, you
>> get a "could not send data to client" error in the log every time a
>> standby disconnects for any reason.
> 
> Yes. And, when walreceiver exits, it sends 'X' message by calling PQfinish().
> So I think it's neater for walsender to treat also 'X'. Thought?

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.

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..

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Dave Page
Date:
Subject: Re: RFC: PostgreSQL Add-On Network
Next
From: Leonardo F
Date:
Subject: Re: Patch: Allow substring/replace() to get/set bit values