Re: recovery_connections cannot start (was Re: master in standby mode croaks)

On Fri, Apr 23, 2010 at 6:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Apr 23, 2010 at 4:10 PM, Heikki Linnakangas
>> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>>> So my proposal would be:
>>>
>>> wal_mode=crash/archive/standby
>>> archive_mode=on/off             # if on, wal_mode must be >= 'archive'
>>> archive_command='command'
>>> max_wal_senders=<integer>       # if > 0, wal_mode must be >= 'archive'
>
>> As a general design comment, I think we should avoid still having an
>> archive_mode GUC but having it do something different.  If we're going
>> to change the semantics, we should also change the name, maybe to
>> "archiving".
>
> Agreed on the general point, but AFAICS that proposal keeps the meaning
> of archive_mode the same as it was.

Well, clearly it doesn't. Someone who thinks they can simply turn
archive_mode=on and set archive_command is going to be sadly
disappointed. Before, archive_mode arguably switched the server
between two "modes", with a whole set of behaviors associated with it:
type of WAL logging, whether the archive runs, number of WAL segments
maintained. Under any of the proposals on the table (other than,
"just adjust the error message", which still seems tempting) it's new
purview will be more limited.

...Robert

...Robert