| From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
|---|---|
| To: | Ahmed Et-tanany <ahmed(dot)ettanany(at)aiven(dot)io> |
| Cc: | Álvaro Herrera <alvherre(at)kurilemu(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH] Add max_logical_replication_slots GUC |
| Date: | 2026-02-04 00:54:57 |
| Message-ID: | CAD21AoBpEGfeX3ce_biQn6wsD+7vb5iEDbu5BV85P8kvOmotnQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jan 28, 2026 at 10:02 PM Ahmed Et-tanany
<ahmed(dot)ettanany(at)aiven(dot)io> wrote:
>
> Yes, that's what I meant.
FYI there is a related discussion on another thread[1]; Now that
wal_level='replica' can dynamically become 'logical' WAL level
depending on the logical slot presence, there might be users who want
to allow physical replication while not for logical replication
(decoding) to avoid overheads due to logical WAL logging. Having
separate limits for logical slots and physical slots might help such
use cases too.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-02-04 01:04:57 | Re: Use allocation macros in the logical replication code |
| Previous Message | Masahiko Sawada | 2026-02-04 00:41:07 | Re: pg_upgrade: optimize replication slot caught-up check |