Re: Bump default wal_level to logical

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Bump default wal_level to logical
Дата
Msg-id 20200608171619.GA11063@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: Bump default wal_level to logical  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: Bump default wal_level to logical  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Bump default wal_level to logical  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 2020-Jun-08, Tomas Vondra wrote:

> Not sure if it's sufficient, though, because switching to logical may
> require bumping up number of slots, walsenders, etc. At which point you
> actually need a restart. Not to mention that extensions using logical
> decoding (like pglogical) need to allocate shared memory etc. But for
> the built-in logical replication that is not an issue, ofc.

I think it's reasonable to push our default limits for slots,
walsenders, max_bgworkers etc a lot higher than current value (say 10 ->
100).  An unused slot wastes essentially no resources; an unused
walsender is just one PGPROC entry.  If we did that, and also allowed
wal_level to be changed on the fly, we wouldn't need to restart in order
to enable logical replication, so there would be little or no pressure
to change the wal_level default.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Getting ERROR with FOR UPDATE/SHARE for partitioned table.
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: possibility to read dumped table's name from file