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  <>

  + It's impossible for everything to be true. +

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to