2010/2/18 Heikki Linnakangas <heikki.linnakan...@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 refused it. >>> [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 refused it. >> >> 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 Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
