Re: problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Fabrice Chapuis <fabrice636861(at)gmail(dot)com>, Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org>
Subject: Re: problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350
Date: 2026-03-02 17:42:52
Message-ID: f393ed522208b1253be393eaf7c66b4637e4d059.camel@cybertec.at
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Mon, 2026-03-02 at 17:13 +0100, Fabrice Chapuis wrote:
> I think the value of max_connections must be aligned with primary because
> the goal is to maintain this sizing in case of a failover and promotion of the standby.

Not every standby is for failover.
The technical reason is that the process array on the standby has to be at least
as big as on the primary (if you are setting "hot_standby = on").

> Why to be conservative with `max_connection` and not with shared buffer?
> If we're performing recovery on a machine with significantly fewer CPU and RAM
> resources than the original server, lowering these parameters could be an option
> because they reserve memory at starting.

Perhaps, but you cannot do it. If that is a requirement, use a connection pool.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Holger Jakobs 2026-03-02 18:16:35 Re: upgrade from 13 to 16
Previous Message Fabrice Chapuis 2026-03-02 16:13:22 Re: problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350