On Tue, Sep 20, 2011 at 3:10 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Tue, Sep 20, 2011 at 1:30 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> Are we all talking about the same thing?  In my mind recovery.conf is
>>> for configuring a point-in-time archive recovery run.  It's got nothing
>>> to do with either replication or standbys.
>> Huh?  How else can you create a standby?  I do it by creating a
>> recovery.conf file that says:
>> standby_mode=on
> The point I'm trying to make is that it seems like this discussion is
> getting driven entirely by the standby case, without remembering that
> recovery.conf was originally designed for, and is still used in,
> a significantly different use-case.  Maybe we had better take two
> steps back and think about the implications for the archive-recovery
> case.

I'm not sure there really are any implications that are worth getting
excited about.  The problem is really one of naming; I'm reminded of
our recent discussions of the use of the term "relation".  The problem
is that the word "recovery" encompasses a number of very different
scenarios.  First, we have crash recovery.  Second, we have archive
recovery (which, confusingly enough, no longer requires an archive).
Archive recovery can be further subdivided by where the xlog files are
coming from (archive, streaming replication, both, or neither) and how
long we plan to stay in recovery (forever, if acting as a standby;
until end of WAL, if promoting a standby or recovering a hot backup;
or until the recovery target is reached, if performing a point in time
recovery).  I would guess that most of those are not what the typical
user thinks of as "recovery", but what else are we gonna call it?
Josh is arguing that we ought to use the term "replication", but it
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.

For now, I think we're best off not changing the terminology, and
confining the remit of this patch to (a) turning all of the existing
recovery.conf parameters into GUCs and (b) replacing recovery.conf
with a sentinel file a sentinel file (name TBB) to indicate that the
server is to start in recovery mode.  The naming isn't great but the
more we change at once the less chance of reaching agreement.  It
seems like we have pretty broad agreement on the basics here, so let's
start with that.

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to