Re: recovery_connections cannot start (was Re: master in standby mode croaks) - Mailing list pgsql-hackers

From Florian Pflug
Subject Re: recovery_connections cannot start (was Re: master in standby mode croaks)
Date
Msg-id 7B086A89-8DF7-4016-B1DD-2A3409200812@phlo.org
Whole thread Raw
In response to Re: recovery_connections cannot start (was Re: master in standby mode croaks)  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
On Apr 23, 2010, at 13:12 , Heikki Linnakangas wrote:
> Let's have these three settings:
>
> wal_mode = crash/archive/standby (replaces archive_mode)
> archive_command
> max_wal_senders
>
> If wal_mode is set to 'crash', you can't set archive_command or
> max_wal_senders>0. If it's set to 'archive', you can set archive_command
> and/or max_wal_senders for archiving and streaming replication, but the
> standby server won't allow queries. If you set it to 'standby', it will
> (assuming you've set recovery_connections=on in the standby).
>
> Note that "wal_mode=standby" replaces "recovery_connections=on" in the
> primary.
>
> I think this would be much easier to understand than the current
> situation. I'm not wedded to the GUC name or values, though, maybe it
> should be archive_mode=off/on/standby, or wal_mode=minimal/archive/full.

Hm, but but that would preclude the possibility of running master and (log-shipping) slave off the same configuration,
sinceone would need wal_mode=standby and the other recovery_connections=on. 

Whereas with the current GUCs, i"archive_mode=on, recovery_connections=on, archive_command=..." should be a valid
configurationfor both master and slave, no? 

best regards,
Florian Pflug



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: recovery_connections cannot start (was Re: master in standby mode croaks)
Next
From: Robert Haas
Date:
Subject: Re: recovery_connections cannot start (was Re: master in standby mode croaks)