Robert Haas wrote:
> I think (as I did/do with Hot Standby) that the most important thing
> here is to get to a point where we have a reasonably good feature that
> is of some use, and commit it. It will probably have some annoying
> limitations; we can remove those later. I have a feel that what we
> have right now is going to be non-robust in the face of network
> breaks, but that is a problem that can be fixed by a future patch.
>
Improving robustness in all the situations where you'd like things to be
better for replication is a never ending job. As I understand it, a
major issue with this patch right now is how it links to the client
libpq. That's the sort of problem that can make this uncomittable. As
long as the fundamentals are good, it's important not to get lost in
optimizing the end UI here if it's at the expense of getting something
you can deploy at all in the process. If Streaming Replication ships
with a working core but a horribly complicated setup/failover mechanism,
that's infinitely better than not shipping at all because resources were
diverted toward making things more robust or easier to setup instead.
Also, the pool of authors who can work on tweaking the smaller details
here is larger than those capable of working on the fundamental
streaming replication code.
--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.com