On Fri, Feb 18, 2011 at 10:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Feb 18, 2011 at 10:09 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> Make a hard state change from catchup to streaming mode.
>>> More useful state change for monitoring purposes, plus a
>>> required change for synchronous replication patch.
>
>> As far as I can see, this patch was not posted or discussed before
>> commit, and I'm not sure it's the behavior everyone wants. It has the
>> effect of preventing the system from ever going backwards from
>> "streaming" to "catchup". Is that what we want?
>
> That seems like a very bad idea from here. Being able to go back to
> catchup after loss of the streaming connection is essential for
> robustness. If we now have to restart the slave for that to happen,
> it's not an improvement.
No, that's not the case where it matters. The state would get reset
on reconnect. The problem is when, say, the master server is
generating WAL at a rate which exceeds the network bandwidth of the
link between the master and the standby. The previous coding will
make us flip back into the catchup state when that happens.
Actually, the old code is awfully sensitive, and knowing that you are
not caught up is not really enough information: you need to know how
far behind you are, and how long you've been behind for. I'm guessing
that Simon intended this patch to deal with that problem, but it's not
the right fix.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
