On Fri, Feb 18, 2011 at 11:50 AM, Robert Haas <robertmh...@gmail.com> wrote: > 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.
So am I the only one who thinks this needs to be reverted? -- 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
