Re: Recovery Test Framework

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:

> Is it flaky? Not fundamentally; code wise I see it more as a
> question of time.

"a question of time" indeed.

> If we insist upon cuts, ...

> Even if we reject replication entirely ...

There's a clear difference between how you're thinking about this and I do.
The way I see it nobody suggested cutting or rejecting anything, just
committing it into a different branch for a different release date. It would
give us a year of experience seeing the code in action before releasing it on
the world.

I'm not sure whether it's too immature to commit, I haven't read the patch;
from what I see in the mailing list it seems about as ready as other large
patches in the past which were committed. But from my point of view it would
just always be better to commit large patches immediately after forking a
release instead of just before the beta to give them a whole release cycle of
exposure to developers before beta testers.

I'm not sure if this is the right release cycle to start this policy, but I
would like to convince people of this at some point so we can start having a
flood of big commits at the *beginning* of the release cycle and then a whole
release cycle of incremental polishing to those features rather than always
having freshly committed features in our releases that none of us has much
experience with.

> a recovery test framework is going to increase the robustness of what we
> *currently* have. It's not a new requirement; what is new is I now have some
> sponsorship money explicitly earmarked for this, but as part of the HS
> project and indeed the test framework relies upon HS to operate at all.

I agree with you that additional tests don't represent any immaturity in the
patch. They don't affect the run-time behaviour and I love the fact that they
might turn up any problems with our existing recovery process.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!