Re: Streaming replication and unfit messages

2010/2/18 Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>:
> Fujii Masao wrote:
>> Hi,
>>
>> When the replication connection is closed unexpectedly, walsender might emit
>> the following unfit messages. IOW, the loss of the connection might be wrongly
>> regarded as an arrival of invalid message by the walsender. This looks messy.
>> We should get rid of that unfit FATAL message, emit a COMMERROR message and
>> just call proc_exit() when the loss of the connection is found?
>>
>>> [2460]: LOG:  could not receive data from client: No connection could be made because the target machine actively
refusedit. 
>>> [2460]: FATAL:  invalid standby closing message type 4
>>> [2460]: LOG:  could not send data to client: No connection could be made because the target machine actively
refusedit. 
>>
>> Also the walsender wrongly tries to send the FATAL message to the standby even
>> though the connection has already been closed, and then gets the following LOG
>> message after the FATAL one. This FATAL message is suitable, but output of the
>> LOG message looks messy, too. We should use COMMERROR instead of FATAL and then
>> just call proc_exit() in order to prevent a message from being sent?
>>
>>> [12586] FATAL:  unexpected EOF on standby connection
>>> [12586] LOG:  could not send data to client: Broken pipe
>>
>> The attached patch fixes those unfit messages.
>
> Actually the pg_getbyte_if_available() function is a bit confused. The
> comment above it claims that it returns 0 if no data is available
> without blocking, but it actually returns -1 with errno==EWOULDBLOCK.
> That stems from confusion in secure_read(); with SSL it returns 0 if it
> would block, but without SSL it returns -1 and EWOULDBLOCK. We should
> fix that so that secure_read() behaves consistently and so that
> pq_getbyte_if_available() behaves like e.g pq_getbytes().
>
> Patch attached for that. pq_getbyte_if_available() now reports any
> errors with COMMERROR level, and returns EOF if the connection is closed
> cleanly. If no data is available without blocking it now really returns
> 0 as the comment said. Walsender reports any unexpected EOF to the log
> at COMMERROR level, similar to what normal backends do.

This cannot possibly be correct:
+             if (errno == EAGAIN || EWOULDBLOCK || errno == EINTR)


The middle argument is missing the errno== part.




-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/