On Fri, Feb 18, 2011 at 11:50 AM, Robert Haas <[email protected]> wrote: > On Fri, Feb 18, 2011 at 10:41 AM, Tom Lane <[email protected]> wrote: >> Robert Haas <[email protected]> writes: >>> On Fri, Feb 18, 2011 at 10:09 AM, Simon Riggs <[email protected]> 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 ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
