On Thu, Jan 29, 2026 at 1:55 PM Euler Taveira <euler@eulerto.com> wrote:
On Thu, Jan 29, 2026, at 8:33 AM, Ahmed Et-tanany wrote: > > I find the idea of a reserved_replication_slots parameter > interesting. However, I'm thinking about the amount of additional > semantics we'd need to introduce to properly manage slot ownership, > since we currently don't have the concept of a role specifically > reserving or owning a replication slot. >
If the role credentials are valid and the role has REPLICATION privilege, it can use any replication slots. The proposal is an extra requirement to allow the role to use a reserved pool of replication slots. I don't think the resource (replication slot) needs ownership and privileges for a fine-grained control.
> It seems to me we'd either keep it simple and focus on just limiting > the number of logical slots, or explore the role-based reservation > idea more in-depth. >
As Fujii said I'm afraid we also need another GUC (for WAL senders) since X active replication slots implies at least X walsenders. In order to guarantee there won't be physical replication interruption, you also need to guarantee that there will be a walsender available.
I started exploring the reserved_replication_slots idea, and unless I'm missing something, the WAL senders issue raised by Fujii still applies there as well. We would therefore still need an additional mechanism (e.g., another GUC such as reserved_wal_senders) to ensure that WAL senders are not entirely consumed by logical replication.
Given that, I'm wondering what would be the preferred way to avoid
introducing two separate GUCs under either approach.
From:
Álvaro Herrera Date: Subject:
Re: getting "shell command argument contains a newline or carriage return:" error with pg_dumpall when db name have new line in double quote
