Re: Streaming replication and unfit messages
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2010-02-18T09:43:41Z
Lists: pgsql-hackers
Attachments
- fix-pq_getbyte_if_available-1.patch (text/x-diff) patch
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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com