Re: ACK from walreceiver to walsender

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ACK from walreceiver to walsender
Date: 2010-01-08 09:39:38
Message-ID: 4B46FD5A.8060609@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fujii Masao wrote:
> On Fri, Jan 8, 2010 at 5:55 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Leonardo F 2010-01-08 09:49:42 Re: Patch: Allow substring/replace() to get/set bit values
Previous Message Dave Page 2010-01-08 09:35:40 Re: RFC: PostgreSQL Add-On Network