Re: unite recovery.conf and postgresql.conf - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: unite recovery.conf and postgresql.conf
Date
Msg-id 201111041654.pA4GscU17806@momjian.us
Whole thread Raw
In response to Re: unite recovery.conf and postgresql.conf  (Josh Berkus <josh@agliodbs.com>)
Responses Re: unite recovery.conf and postgresql.conf
List pgsql-hackers
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. +


pgsql-hackers by date:

Previous
From: Marti Raudsepp
Date:
Subject: Re: IDLE in transaction introspection
Next
From: Bruce Momjian
Date:
Subject: Re: TOAST versus VACUUM, or "missing chunk number 0 for toast value" identified