On Fri, Feb 18, 2011 at 10:41 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Feb 18, 2011 at 10:09 AM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
