Re: recovery_connections cannot start (was Re: master in standby mode croaks)
От | Florian Pflug |
---|---|
Тема | Re: recovery_connections cannot start (was Re: master in standby mode croaks) |
Дата | |
Msg-id | 7B086A89-8DF7-4016-B1DD-2A3409200812@phlo.org обсуждение исходный текст |
Ответ на | Re: recovery_connections cannot start (was Re: master in standby mode croaks) (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | 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 по дате отправления: