public inbox for [email protected]  

help / color / mirror / Atom feed

Operational issues when max_replication_slots is exhausted
3+ messages / 3 participants
[nested] [flat]

* Operational issues when max_replication_slots is exhausted
@ 2025-12-15 11:58 Ahmed Et-tanany <[email protected]>
  2025-12-15 15:17 ` Re: Operational issues when max_replication_slots is exhausted Laurenz Albe <[email protected]>
  2025-12-15 16:25 ` Re: Operational issues when max_replication_slots is exhausted Adrian Klaver <[email protected]>
  0 siblings, 2 replies; 3+ messages in thread

From: Ahmed Et-tanany @ 2025-12-15 11:58 UTC (permalink / raw)
  To: [email protected]

Hello PostgreSQL community,

We have an issue related to `max_replication_slots` that I am not sure
would qualify as a bug,
so I thought I would ask here first.

Our problem is that when our customers use up all available replication
slots for logical replication,
our database management tasks that also require a slot fail (for example,
creating the required
replication slot for a new physical standby). Since increasing
`max_replication_slots` requires
a restart, we would like to avoid that if possible.

One idea we have considered is patching PostgreSQL to add a new GUC
parameter that would allow
a superuser to reserve a certain number of replication slots usable only
for management tasks.

Is this a known issue that might be addressed in PostgreSQL at some point?
If not,
what would be a good way to solve this problem?

Thanks in advance.

Best regards,

-- 
Ahmed Et-tanany
Aiven: https://aiven.io/


^ permalink  raw  reply  [nested|flat] 3+ messages in thread

* Re: Operational issues when max_replication_slots is exhausted
  2025-12-15 11:58 Operational issues when max_replication_slots is exhausted Ahmed Et-tanany <[email protected]>
@ 2025-12-15 15:17 ` Laurenz Albe <[email protected]>
  1 sibling, 0 replies; 3+ messages in thread

From: Laurenz Albe @ 2025-12-15 15:17 UTC (permalink / raw)
  To: Ahmed Et-tanany <[email protected]>; [email protected]

On Mon, 2025-12-15 at 12:58 +0100, Ahmed Et-tanany wrote:
> Our problem is that when our customers use up all available replication slots for logical replication,
> our database management tasks that also require a slot fail (for example, creating the required
> replication slot for a new physical standby). Since increasing `max_replication_slots` requires
> a restart, we would like to avoid that if possible.
> 
> One idea we have considered is patching PostgreSQL to add a new GUC parameter that would allow
> a superuser to reserve a certain number of replication slots usable only for management tasks.
> 
> Is this a known issue that might be addressed in PostgreSQL at some point? If not,
> what would be a good way to solve this problem?

It is conceivable that somebody might change the behavior at some point (compare
"reserved_connections").  If you write or sponsor a patch, that would increase
the likelihood.

Right now, my only suggestion is to set "max_replication_slots" high.

Yours,
Laurenz Albe






^ permalink  raw  reply  [nested|flat] 3+ messages in thread

* Re: Operational issues when max_replication_slots is exhausted
  2025-12-15 11:58 Operational issues when max_replication_slots is exhausted Ahmed Et-tanany <[email protected]>
@ 2025-12-15 16:25 ` Adrian Klaver <[email protected]>
  1 sibling, 0 replies; 3+ messages in thread

From: Adrian Klaver @ 2025-12-15 16:25 UTC (permalink / raw)
  To: Ahmed Et-tanany <[email protected]>; [email protected]

On 12/15/25 03:58, Ahmed Et-tanany wrote:
> Hello PostgreSQL community,
> 
> We have an issue related to `max_replication_slots` that I am not sure 
> would qualify as a bug,
> so I thought I would ask here first.
> 
> Our problem is that when our customers use up all available replication 
> slots for logical replication,

The above would be the issue. Allowing customers to be DBA's for an 
installation that they are not ultimately responsible for does not seem 
sound to me. I would think a request mechanism is in order.


> 
> Thanks in advance.
> 
> Best regards,
> 
> -- 
> Ahmed Et-tanany
> Aiven: https://aiven.io/ <https://aiven.io/;


-- 
Adrian Klaver
[email protected]






^ permalink  raw  reply  [nested|flat] 3+ messages in thread

end of thread, other threads:[~2025-12-15 16:25 UTC | newest]

Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-12-15 11:58 Operational issues when max_replication_slots is exhausted Ahmed Et-tanany <[email protected]>
2025-12-15 15:17 ` Laurenz Albe <[email protected]>
2025-12-15 16:25 ` Adrian Klaver <[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