Re: Sync Rep for 2011CF1
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Fujii Masao <masao.fujii@gmail.com>, pgsql-hackers@postgresql.org
Date: 2011-02-16T15:40:41Z
Lists: pgsql-hackers
On 16.02.2011 17:36, Simon Riggs wrote: > On Tue, 2011-02-15 at 12:08 -0500, Robert Haas wrote: >> On Mon, Feb 14, 2011 at 12:25 AM, Fujii Masao<masao.fujii@gmail.com> wrote: >>> On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas >>> <heikki.linnakangas@enterprisedb.com> wrote: >>>> I added a XLogWalRcvSendReply() call into XLogWalRcvFlush() so that it also >>>> sends a status update every time the WAL is flushed. If the walreceiver is >>>> busy receiving and flushing, that would happen once per WAL segment, which >>>> seems sensible. >>> >>> This change can make the callback function "WalRcvDie()" call ereport(ERROR) >>> via XLogWalRcvFlush(). This looks unsafe. >> >> Good catch. Is the cleanest solution to pass a boolean parameter to >> XLogWalRcvFlush() indicating whether we're in the midst of dying? > > Surely if you do this then sync rep will fail to respond correctly if > WalReceiver dies. > > Why is it OK to write to disk, but not OK to reply? Because the connection might be dead. A broken connection is a likely cause of walreceiver death. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com