Re: recovery_connections cannot start (was Re: master in standby mode croaks)
От | Simon Riggs |
---|---|
Тема | Re: recovery_connections cannot start (was Re: master in standby mode croaks) |
Дата | |
Msg-id | 1272060236.4161.844.camel@ebony обсуждение исходный текст |
Ответ на | Re: recovery_connections cannot start (was Re: master in standby mode croaks) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: recovery_connections cannot start (was Re: master in standby mode croaks)
|
Список | pgsql-hackers |
On Fri, 2010-04-23 at 17:43 -0400, Robert Haas wrote: > On Fri, Apr 23, 2010 at 4:10 PM, Heikki Linnakangas > <heikki.linnakangas@enterprisedb.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". We don't need *both* wal_mode and archive_mode, since archive_mode exists only to ensure that full WAL is written even when archive_command = '' momentarily. Should do this > > wal_mode=crash/archive/standby > > archive_command='command' > > max_wal_senders=<integer> # if > 0, wal_mode must be >= 'archive' and make wal_mode SIGHUP -- Simon Riggs www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: