Josh Berkus wrote:
> > We can always do nothing, which is a safe and viable option.
>
> Not really, no. The whole recovery.conf thing is very broken and
> inhibits adoption of PostgreSQL because our users can't figure it out.
>
> You've made it pretty clear that you're personally comfortable with how
> replication configuration works now, and aren't really interested in any
> changes. That's certainly a valid viewpoint, but the users and
> contributors who find the API horribly unusable also have a valid
> viewpoint. You don't automatically win arguments because you're on the
> side of backwards compatibility.
>
> When we released binary replication in 9.0, I thought everyone knew that
> it was a first cut and that we'd be making some dramatic changes --
> including ones which broke things -- over the next few versions. There
> was simply no way for us to know real user requirements until the
> feature was in the field and being deployed in production. We would
> discover some things which really didn't work and that we had to break
> and remake. And we have.
>
> Now you are arguing for premature senescence, where our first API
> becomes our only API now and forever. That's a road to project death.
Agreed. This thread has already expended too much of our valuable time,
in my opinion.
I think we have enough agreement that we need a new API, so let's design
one. If we can add some backward-compatibility here, great, but let's
not have that driving the discussion. Replication is already complex
enough that having two ways to set this up just adds confusion.
Replication/PITR does not affect SQL or applications --- it affects
admin scripts and tools, so they are just going to have to adjust.
We are not going to make everyone happy, so let's just move forward ---
if people want to pout in the corner, I really don't care.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +