Re: allowing wal_level change at run time

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: allowing wal_level change at run time
Дата
Msg-id 20150820195042.GC8552@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: allowing wal_level change at run time  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: allowing wal_level change at run time  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
On 2015-08-20 15:11:02 -0400, Peter Eisentraut wrote:
> It seems to me that this would effectively replace the wal_level
> parameter with the presence or absence of a magic replication slot.
> That doesn't seem like a net improvement.  It just replaces one
> well-known configuration mechanism with a new ad hoc one.

Well, with the difference that it can be changed automatically. We could
alternatively automagically use ALTER SYSTEM, but that's not really
guaranteed to work and isn't available via the replication protocol
currently. But I could live with that as well.

> >> Also note that this scheme and any similar one requires merging the
> >> archive and hot_standby levels, which was the core of your original
> >> proposal [1]
> > 
> > It doesn't really, we could continue to keep them separate. I'm
> > proposing to maintain wal_level automatically, so it'd not be
> > configurable anymore, so it'd not matter much, as long as we're not less
> > efficient.
> 
> But, under any scheme to set wal_level automatically, how will the
> primary know whether it needs to use level archive or hot_standby?

I'd have said archive_mode triggered archive and everything else
hot_standby.  I am still of the opinion though that the difference
between those two levels is meaningless and that we should remove
archive.

Andres



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Feng Tian
Дата:
Сообщение: Re: Using quicksort for every external sort run
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: DBT-3 with SF=20 got failed