Simon Riggs <si...@2ndquadrant.com> writes: > On Wed, 2009-01-28 at 14:56 -0500, Tom Lane wrote: > >> Well, those unexpectedly cancelled queries could have represented >> critical functionality too. I think this argument calls the entire >> approach into question. If there is no safe setting for the parameter >> then we need to find a way to not have the parameter. > > I see the opposite: We don't know what tradeoffs, if any, the user is > willing to put up with, so we need input.
Well, if you see it that way then it seems to me you should be arguing for making max_standby_delay a mandatory parameter. Without it don't start allow connections. I hadn't considered that and am not exactly sure where I would stand on it. > The essential choice is "What would you like the max failover time to > be?". Some users want one server with max 5 mins behind, some want two > servers, one with 0 seconds behind, one with 12 hours behind Sure. But if they don't configure one then we shouldn't impose one. You're thinking of precisely one use case and taking positive action to interrupt the user's requests on the basis of it. But there are plenty of other use cases. I claim the default has to be to do as the user instructed without intervention. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
