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 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. > 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. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers