public inbox for [email protected]help / color / mirror / Atom feed
Re: [PATCH] Add max_logical_replication_slots GUC 10+ messages / 6 participants [nested] [flat]
* Re: [PATCH] Add max_logical_replication_slots GUC @ 2026-01-28 12:42 Ahmed Et-tanany <[email protected]> 0 siblings, 1 reply; 10+ messages in thread From: Ahmed Et-tanany @ 2026-01-28 12:42 UTC (permalink / raw) To: Álvaro Herrera <[email protected]>; +Cc: [email protected] Right now, all replication slots share a single global limit: max_replication_slots. That means logical and physical replication slots compete for the same pool. In practice, a burst of logical replication activity can exhaust all available replication slots, which in turn prevents physical standbys from connecting or restarting. This is problematic because logical replication slots are often user-managed and can grow dynamically, while physical replication slots are infrastructure-critical and expected to remain available. Best regards, -- Ahmed Et-tanany Aiven: https://aiven.io/ On Wed, Jan 28, 2026 at 1:28 PM Álvaro Herrera <[email protected]> wrote: > Hello, > > On 2026-Jan-28, Ahmed Et-tanany wrote: > > > This provides a separation between logical and total replication > > slots, and allows users to control logical slot usage independently. > > Hmm, why is this useful? > > -- > Álvaro Herrera 48°01'N 7°57'E — > https://www.EnterpriseDB.com/ > "Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end." (2nd Commandment for C programmers) > -- [image: Aiven] <https://www.aiven.io; *Ahmed Et-tanany* Software Engineer, *Aiven* [email protected] | +491772950423 aiven.io <https://www.aiven.io; | <https://www.facebook.com/aivencloud; <https://www.linkedin.com/company/aiven/; <https://twitter.com/aiven_io; *Aiven Deutschland GmbH* Alexanderufer 3-7, 10117 Berlin Geschäftsführer: Oskari Saarenmaa, Kenneth Chen Amtsgericht Charlottenburg, HRB 209739 B ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Add max_logical_replication_slots GUC @ 2026-01-28 12:54 Álvaro Herrera <[email protected]> parent: Ahmed Et-tanany <[email protected]> 0 siblings, 1 reply; 10+ messages in thread From: Álvaro Herrera @ 2026-01-28 12:54 UTC (permalink / raw) To: Ahmed Et-tanany <[email protected]>; +Cc: [email protected] On 2026-Jan-28, Ahmed Et-tanany wrote: > In practice, a burst of logical replication activity can exhaust all > available replication slots, which in turn prevents physical standbys > from connecting or restarting. > > This is problematic because logical replication slots are often > user-managed and can grow dynamically, Ah, you mean that users doing CREATE SUBSCRIPTION could cause the limit to be reached, possibly blocking streaming replication. Yeah, it makes sense to have a separate limit. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "[PostgreSQL] is a great group; in my opinion it is THE best open source development communities in existence anywhere." (Lamar Owen) ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Add max_logical_replication_slots GUC @ 2026-01-28 13:02 Ahmed Et-tanany <[email protected]> parent: Álvaro Herrera <[email protected]> 0 siblings, 2 replies; 10+ messages in thread From: Ahmed Et-tanany @ 2026-01-28 13:02 UTC (permalink / raw) To: Álvaro Herrera <[email protected]>; +Cc: [email protected] Yes, that's what I meant. On Wed, Jan 28, 2026 at 1:55 PM Álvaro Herrera <[email protected]> wrote: > On 2026-Jan-28, Ahmed Et-tanany wrote: > > > In practice, a burst of logical replication activity can exhaust all > > available replication slots, which in turn prevents physical standbys > > from connecting or restarting. > > > > This is problematic because logical replication slots are often > > user-managed and can grow dynamically, > > Ah, you mean that users doing CREATE SUBSCRIPTION could cause the limit > to be reached, possibly blocking streaming replication. Yeah, it makes > sense to have a separate limit. > > -- > Álvaro Herrera PostgreSQL Developer — > https://www.EnterpriseDB.com/ > "[PostgreSQL] is a great group; in my opinion it is THE best open source > development communities in existence anywhere." (Lamar Owen) > -- Ahmed Et-tanany Aiven: https://aiven.io/ ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Add max_logical_replication_slots GUC @ 2026-01-29 11:39 Fujii Masao <[email protected]> parent: Ahmed Et-tanany <[email protected]> 1 sibling, 3 replies; 10+ messages in thread From: Fujii Masao @ 2026-01-29 11:39 UTC (permalink / raw) To: Ahmed Et-tanany <[email protected]>; +Cc: Álvaro Herrera <[email protected]>; [email protected] On Wed, Jan 28, 2026 at 10:02 PM Ahmed Et-tanany <[email protected]> wrote: > > Yes, that's what I meant. Would something like max_logical_wal_senders also be needed for your purpose? Otherwise, logical replication connections could exhaust max_wal_senders and prevent physical replication connections from being established. That said, adding two separate GUC parameters (i.e., max_logical_replication_slots and max_logical_wal_senders) for this purpose doesn't seem like a great solution, though... Regards, -- Fujii Masao ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Add max_logical_replication_slots GUC @ 2026-01-29 13:01 Ahmed Et-tanany <[email protected]> parent: Fujii Masao <[email protected]> 2 siblings, 1 reply; 10+ messages in thread From: Ahmed Et-tanany @ 2026-01-29 13:01 UTC (permalink / raw) To: Fujii Masao <[email protected]>; +Cc: Álvaro Herrera <[email protected]>; [email protected] On Thu, Jan 29, 2026 at 12:39 PM Fujii Masao <[email protected]> wrote: > > Would something like max_logical_wal_senders also be needed for your > purpose? > Otherwise, logical replication connections could exhaust max_wal_senders > and > prevent physical replication connections from being established. > > That said, adding two separate GUC parameters (i.e., > max_logical_replication_slots > and max_logical_wal_senders) for this purpose doesn't seem like a > great solution, > though... > > That's a great point! I'm thinking we could potentially avoid introducing a separate max_logical_wal_senders GUC by reusing max_logical_replication_slots to decide whether a WAL sender can start for logical replication. This way, the limit on logical slots would also indirectly cap the number of logical WAL senders, helping protect physical replication connections without adding another configuration parameter. What do you think about this approach? Best regards, -- Ahmed Et-tanany Aiven: https://aiven.io/ ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Add max_logical_replication_slots GUC @ 2026-02-04 00:54 Masahiko Sawada <[email protected]> parent: Ahmed Et-tanany <[email protected]> 1 sibling, 0 replies; 10+ messages in thread From: Masahiko Sawada @ 2026-02-04 00:54 UTC (permalink / raw) To: Ahmed Et-tanany <[email protected]>; +Cc: Álvaro Herrera <[email protected]>; [email protected] On Wed, Jan 28, 2026 at 10:02 PM Ahmed Et-tanany <[email protected]> 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, [1] https://www.postgresql.org/message-id/CAEze2WjP0NpAjNioXzLiNkpNQcxCMtaNajaQXfufYVcyFyqW1g%40mail.gma... -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Add max_logical_replication_slots GUC @ 2026-02-11 12:09 Amit Kapila <[email protected]> parent: Ahmed Et-tanany <[email protected]> 0 siblings, 0 replies; 10+ messages in thread From: Amit Kapila @ 2026-02-11 12:09 UTC (permalink / raw) To: Ahmed Et-tanany <[email protected]>; +Cc: Fujii Masao <[email protected]>; Álvaro Herrera <[email protected]>; [email protected] On Thu, Jan 29, 2026 at 6:31 PM Ahmed Et-tanany <[email protected]> wrote: > > On Thu, Jan 29, 2026 at 12:39 PM Fujii Masao <[email protected]> wrote: >> >> >> Would something like max_logical_wal_senders also be needed for your purpose? >> Otherwise, logical replication connections could exhaust max_wal_senders and >> prevent physical replication connections from being established. >> >> That said, adding two separate GUC parameters (i.e., >> max_logical_replication_slots >> and max_logical_wal_senders) for this purpose doesn't seem like a >> great solution, >> though... >> > > That's a great point! I'm thinking we could potentially avoid > introducing a separate max_logical_wal_senders GUC by reusing > max_logical_replication_slots to decide whether a WAL sender can > start for logical replication. > Won't the walsender automatically exit if the max_logical_replication_slots is reached? If so, do we really need a separate GUC to control logical walsenders? -- With Regards, Amit Kapila. ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Add max_logical_replication_slots GUC @ 2026-03-09 16:09 Ahmed Et-tanany <[email protected]> parent: Fujii Masao <[email protected]> 2 siblings, 0 replies; 10+ messages in thread From: Ahmed Et-tanany @ 2026-03-09 16:09 UTC (permalink / raw) To: Fujii Masao <[email protected]>; +Cc: Álvaro Herrera <[email protected]>; [email protected] On Thu, Jan 29, 2026 at 12:39 PM Fujii Masao <[email protected]> wrote: > Would something like max_logical_wal_senders also be needed for your > purpose? > Otherwise, logical replication connections could exhaust max_wal_senders > and > prevent physical replication connections from being established. > > That said, adding two separate GUC parameters (i.e., > max_logical_replication_slots > and max_logical_wal_senders) for this purpose doesn't seem like a > great solution, > though... > For my purpose, it doesn't actually seem that I would need max_logical_wal_senders to limit WAL senders. Since each logical connection always requires a logical replication slot, the actual number of active logical connections (and logical WAL senders) would ultimately be bounded by max_logical_replication_slots. My main concern is therefore slot exhaustion rather than the WAL sender limit. -- Ahmed Et-tanany Aiven: https://aiven.io/ ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Add max_logical_replication_slots GUC @ 2026-03-10 06:54 shveta malik <[email protected]> parent: Fujii Masao <[email protected]> 2 siblings, 1 reply; 10+ messages in thread From: shveta malik @ 2026-03-10 06:54 UTC (permalink / raw) To: Fujii Masao <[email protected]>; +Cc: Ahmed Et-tanany <[email protected]>; Álvaro Herrera <[email protected]>; [email protected]; shveta malik <[email protected]> On Thu, Jan 29, 2026 at 5:10 PM Fujii Masao <[email protected]> wrote: > > On Wed, Jan 28, 2026 at 10:02 PM Ahmed Et-tanany > <[email protected]> wrote: > > > > Yes, that's what I meant. > > Would something like max_logical_wal_senders also be needed for your purpose? > Otherwise, logical replication connections could exhaust max_wal_senders and > prevent physical replication connections from being established. > I could be mistaken, but I haven’t found a way to start a logical replication stream without a replication slot. A replication connection and walsender can exist without a slot, for example: ./psql "host=localhost port=5432 user=user1 dbname=postgres replication=database" However, converting that connection to logical replication requires a slot from the max_logical_replication_slots pool. If that pool is exhausted, the connection cannot be converted — in which case, wouldn’t a single GUC suffice? I might be missing something — are you referring to a different scenario? One possibility is if max_wal_senders is lower than max_logical_replication_slots, which could exhaust WAL senders for logical connections, though that would mostly be a configuration issue. Isn't it? thanks Shveta ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Add max_logical_replication_slots GUC @ 2026-03-24 00:13 Masahiko Sawada <[email protected]> parent: shveta malik <[email protected]> 0 siblings, 0 replies; 10+ messages in thread From: Masahiko Sawada @ 2026-03-24 00:13 UTC (permalink / raw) To: shveta malik <[email protected]>; +Cc: Fujii Masao <[email protected]>; Ahmed Et-tanany <[email protected]>; Álvaro Herrera <[email protected]>; [email protected] Hi, On Mon, Mar 9, 2026 at 11:55 PM shveta malik <[email protected]> wrote: > > On Thu, Jan 29, 2026 at 5:10 PM Fujii Masao <[email protected]> wrote: > > > > On Wed, Jan 28, 2026 at 10:02 PM Ahmed Et-tanany > > <[email protected]> wrote: > > > > > > Yes, that's what I meant. > > > > Would something like max_logical_wal_senders also be needed for your purpose? > > Otherwise, logical replication connections could exhaust max_wal_senders and > > prevent physical replication connections from being established. > > > > I could be mistaken, but I haven’t found a way to start a logical > replication stream without a replication slot. A replication > connection and walsender can exist without a slot, for example: > ./psql "host=localhost port=5432 user=user1 dbname=postgres > replication=database" > > However, converting that connection to logical replication requires a > slot from the max_logical_replication_slots pool. If that pool is > exhausted, the connection cannot be converted — in which case, > wouldn’t a single GUC suffice? In an extreme case like where if all walsenders are used up by logical walsender who are just connecting and not using logical replication slots, physical replication cannot start even if there is a free physical replication slot. But I think it's sufficient to have something like max_logical_replication_slots in most cases. So a single GUC seems to suffice unless I'm not missing some cases. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com ^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2026-03-24 00:13 UTC | newest] Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-01-28 12:42 Re: [PATCH] Add max_logical_replication_slots GUC Ahmed Et-tanany <[email protected]> 2026-01-28 12:54 ` Álvaro Herrera <[email protected]> 2026-01-28 13:02 ` Ahmed Et-tanany <[email protected]> 2026-01-29 11:39 ` Fujii Masao <[email protected]> 2026-01-29 13:01 ` Ahmed Et-tanany <[email protected]> 2026-02-11 12:09 ` Amit Kapila <[email protected]> 2026-03-09 16:09 ` Ahmed Et-tanany <[email protected]> 2026-03-10 06:54 ` shveta malik <[email protected]> 2026-03-24 00:13 ` Masahiko Sawada <[email protected]> 2026-02-04 00:54 ` Masahiko Sawada <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox