Re: unite recovery.conf and postgresql.conf

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>

To: Josh Berkus <josh@agliodbs.com>

Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org

Date: 2011-09-21T16:57:46Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Restructure error handling in reading of postgresql.conf.
- d56b3afc0376 9.2.0 cited

On Wed, Sep 21, 2011 at 12:55 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> Josh is arguing that we ought to use the term "replication", but it
>
> Actually, no. I'm arguing that we should use the term "standby", since
> that term is consistent with how we refer to replica servers throughout
> the docs, and the term "recovery" is not.
>
>> seems to me that's just as misleading - maybe moreso, since "recovery"
>> is sufficiently a term of art to make you at least think about reading
>> the manual, whereas you know (or think you know) what replication is.
>
> Nope.  What it means is that users see stuff relating to "recovery" and
> say "oh, that's not right, the replication stuff must be somewhere else".
>
> I've taught a half-dozen classes on PostgreSQL binary replication now,
> and the "recovery" nomenclature *always* confuses students.

Yeah, I get it.  But I think standby would confuse them, too, just in
a different set of situations.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company