Re: Streaming replication and a disk full in primary
От | Heikki Linnakangas |
---|---|
Тема | Re: Streaming replication and a disk full in primary |
Дата | |
Msg-id | 4BC49410.8080702@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Streaming replication and a disk full in primary (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Streaming replication and a disk full in primary
|
Список | pgsql-hackers |
Robert Haas wrote: > On Mon, Apr 12, 2010 at 6:41 AM, Heikki Linnakangas > <heikki.linnakangas@enterprisedb.com> wrote: >>> Why is standby_keep_segments used even if max_wal_senders is zero? >>> In that case, ISTM we don't need to keep any WAL files in pg_xlog >>> for the standby. >> True. I don't think we should second guess the admin on that, though. >> Perhaps he only set max_wal_senders=0 temporarily, and will be >> disappointed if the the logs are no longer there when he sets it back to >> non-zero and restarts the server. > > If archive_mode is off and max_wal_senders = 0, then the WAL that's > being generated won't be usable for streaming anyway, right? > > I think this is another manifestation of the problem I was complaining > about over the weekend: there's no longer a single GUC that controls > what type of information we emit as WAL. In previous releases, > archive_mode served that function, but now it's much more complicated > and, IMHO, not very comprehensible. > > http://archives.postgresql.org/pgsql-hackers/2010-04/msg00509.php Agreed. We've been trying to deduce from other settings what information needs to be WAL-logged, but it hasn't been a great success so it would be better to make it explicit than try to hide it. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: