Re: allowing wal_level change at run time

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: allowing wal_level change at run time
Дата
Msg-id CABUevEy15Y=sF8doKjD86eujJZL=Tq2jyUSiYVkg6EVwVt=cag@mail.gmail.com
обсуждение исходный текст
Ответ на allowing wal_level change at run time  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
On Tue, Aug 18, 2015 at 1:59 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
In [1], it was discussed to make wal_level changeable at run time
(PGC_SIGHUP), as part of an effort to make replication easier to set up
and/or provide better defaults.  I was wondering what it would take to
do that.

I looks like increasing the setting is doable, as long as we WAL-log the
change using existing facilities.  I don't understand the hot_standby ->
logical transition, so maybe something else is necessary there.

How would we handle decreases at run time?  We can prevent >=archive ->
minimal if archiving is running or there are physical replication slots,
and we can prevent logical -> something less if there are logical
replication slots, but AFAICT, we don't have a way to check whether
anyone currently needs level hot_standby.  (Thread [1] originally
proposed to get rid of the archive/hot_standby distinction, which would
help here.)  Or we could just let users make their own mess if they want to.


I still think we should get rid of the difference between archive/hot_standby. It creates more trouble than I've ever seen it save. I think we can safely label that as something we added because we didn't know if it was going to be needed (because back in 9.0 nobody knew what the impact *really* would be), but now we know it's not necessary so we can just get rid of it.

Especially as it makes something like this easier. Removing complexity of such important parts of the code is a feature in itself! 

--

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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: allowing wal_level change at run time
Следующее
От: Robert Haas
Дата:
Сообщение: Re: allowing wal_level change at run time