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: http://www.postgresql.org/mailpref/pgsql-hackers