On 2013-08-08 10:51:45 -0700, Josh Berkus wrote: > On 08/08/2013 10:34 AM, Andres Freund wrote: > > On 2013-08-08 10:15:14 -0700, Josh Berkus wrote: > >> Either we have confidence is fast promotion, or we don't. If we don't > >> have confidence, then either (a) more testing is needed, or (b) it > >> shouldn't be the default. Again, here, we are coming up against our > >> lack of any kind of broad replication failure testing. > > > > While I think we definitely miss out there I don't think any regression > > suite would help much here. I am wary of unknown problems, not ones > > we already have tests for. The subtle ones aren't easy to test, even > > with a regression suite. > > Yeah, that's why we have to get beyond the mentality that regression > testing is the only kind of testing. We need a destruction test for > replication, and that's NOT going to be a regression test. Among other > things, we'll probably need to run it on cloud hosting.
The point is, that will still mostly produce scenarios we know of. > > The problem is that, especially involving HS, there's lots of subtle > > corner cases. And those are pretty hard to forsee and thus hard to > > test. > > It would be useful to assemble a list of corner cases we *do* know > about. This could become a test suite, and we could keep adding to it. The first thing would be to build the infrastructure for HS testing. Unfortunately I don't have the time/energy for that atm. Unless somebody steps up, this won't happen :( > > Being able to tell somebody to touch some file and kill a certain > > process instead of pg_ctl triggering is certainly better than to have > > them apply complex patches which then only exhibit the old behaviour. > > It's not about letting people regularly use it or such. It's about being > > able to verify problems. > > The problem is, if failover fails badly, the user is probably facing a > corrupt database, downtime, loss of data, and restore from backup. So > if we don't think that fast failover is rock-solid trustworthy --- or at > least as trustworthy as slow failover was -- then we should be making it > a non-default option for 9.3. We shouldn't be exposing people who don't > need fast failover to new risks without their knowledge. I don't think anybody working on related areas of the code thinks it's rock solid. But anyway, I just don't see the downside of allowing problem analysis. You're free to do more testing, review, whatever before the release. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
