| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Bump default wal_level to logical |
| Date: | 2020-06-08 17:16:19 |
| Message-ID: | 20200608171619.GA11063@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2020-06-08 17:18:49 | Re: proposal: possibility to read dumped table's name from file |
| Previous Message | Alvaro Herrera | 2020-06-08 16:39:32 | Re: Getting ERROR with FOR UPDATE/SHARE for partitioned table. |