public inbox for [email protected]
help / color / mirror / Atom feedproblem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350
6+ messages / 3 participants
[nested] [flat]
* problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350
@ 2026-03-02 10:27 Fabrice Chapuis <[email protected]>
2026-03-02 11:05 ` AW: problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350 Patolla Bernd <[email protected]>
2026-03-02 14:36 ` Re: problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350 Laurenz Albe <[email protected]>
0 siblings, 2 replies; 6+ messages in thread
From: Fabrice Chapuis @ 2026-03-02 10:27 UTC (permalink / raw)
To: Pgsql-admin <[email protected]>
Hi,
I got this error from restoring a backup on a recovery machine.
I got error about the max_connections that I changed from 350 to 100.
in the control file the value is 350
/usr/pgsql-17/bin/pg_controldata -D /pgdata/pgsql/17/main/ | grep max_conn
max_connections setting: 350
That is the value registered from the primary. But the primary is not
intended to be connected during this restore.
primary_conninfo is desactivated.
Is there a trick to change decrease this value and start the instance.
Thanks for your help
Fabrice
2026-03-02 11:14:30.353 CET [1620147]: [3-1] user=,db=,client=,application=
LOG: starting PostgreSQL 17.7 on x86_64-pc-linux-gnu, compiled by gcc
(GCC) 11.5.0 20240719 (Red Hat 11.5.0-11), 64-bit
2026-03-02 11:14:30.354 CET [1620147]: [4-1] user=,db=,client=,application=
LOG: listening on IPv4 address "0.0.0.0", port 5432
2026-03-02 11:14:30.354 CET [1620147]: [5-1] user=,db=,client=,application=
LOG: listening on IPv6 address "::", port 5432
2026-03-02 11:14:30.355 CET [1620147]: [6-1] user=,db=,client=,application=
LOG: listening on Unix socket "/run/postgresql/.s.PGSQL.5432"
2026-03-02 11:14:30.357 CET [1620147]: [7-1] user=,db=,client=,application=
LOG: listening on Unix socket "/tmp/.s.PGSQL.5432"
2026-03-02 11:14:30.362 CET [1620154]: [1-1] user=,db=,client=,application=
LOG: database system was interrupted; last known up at 2026-02-25 18:00:01
CET
2026-03-02 11:14:30.362 CET [1620154]: [2-1] user=,db=,client=,application=
LOG: creating missing WAL directory "pg_wal/summaries"
ERROR: The required file is not available: 0000000A.history
2026-03-02 11:14:31.415 CET [1620154]: [3-1] user=,db=,client=,application=
LOG: starting backup recovery with redo LSN 3FB0/D9000028, checkpoint LSN
3FB0/D9010058, on timeline ID 9
2026-03-02 11:14:32.013 CET [1620154]: [4-1] user=,db=,client=,application=
LOG: restored log file "00000009.history" from archive
2026-03-02 11:14:32.748 CET [1620154]: [5-1] user=,db=,client=,application=
LOG: restored log file "0000000900003FB0000000D9" from archive
2026-03-02 11:14:32.749 CET [1620154]: [6-1] user=,db=,client=,application=
LOG: starting point-in-time recovery to 2026-03-02 09:00:00+01
2026-03-02 11:14:32.760 CET [1620154]: [7-1] user=,db=,client=,application=
LOG: recovered replication state of node 1 to 3FB0/D8D74100
2026-03-02 11:14:32.761 CET [1620154]: [8-1] user=,db=,client=,application=
LOG: recovered replication state of node 2 to 3FB0/BB7C1518
2026-03-02 11:14:32.761 CET [1620154]: [9-1] user=,db=,client=,application=
LOG: recovered replication state of node 3 to 3CBD/DDE26700
2026-03-02 11:14:32.761 CET [1620154]: [10-1]
user=,db=,client=,application= FATAL: recovery aborted because of
insufficient parameter settings
2026-03-02 11:14:32.761 CET [1620154]: [11-1]
user=,db=,client=,application= DETAIL: max_connections = 100 is a lower
setting than on the primary server, where its value was 350.
2026-03-02 11:14:32.761 CET [1620154]: [12-1]
user=,db=,client=,application= HINT: You can restart the server after
making the necessary configuration changes.
2026-03-02 11:14:32.762 CET [1620147]: [8-1] user=,db=,client=,application=
LOG: startup process (PID 1620154) exited with exit code 1
2026-03-02 11:14:32.763 CET [1620147]: [9-1] user=,db=,client=,application=
LOG: aborting startup due to startup process failure
2026-03-02 11:14:32.763 CET [1620147]: [10-1]
user=,db=,client=,application= LOG: database system is shut down
^ permalink raw reply [nested|flat] 6+ messages in thread
* AW: problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350
2026-03-02 10:27 problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350 Fabrice Chapuis <[email protected]>
@ 2026-03-02 11:05 ` Patolla Bernd <[email protected]>
1 sibling, 0 replies; 6+ messages in thread
From: Patolla Bernd @ 2026-03-02 11:05 UTC (permalink / raw)
To: Fabrice Chapuis <[email protected]>; Pgsql-admin <[email protected]>
Hi,
In the past we had this issue, too.
Therefore, we scan the control file and set the values from the control file into the postgresql.auto.conf file.
Then we started postgres for recovery, stopped it and set the values to the planned ones.
max_connections and max_worker_processes are the critical parameters to consider in such a scenario.
BR Bernd
Von: Fabrice Chapuis <[email protected]>
Datum: Montag, 2. März 2026 um 11:57
An: Pgsql-admin <[email protected]>
Betreff: problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350
Hi,
I got this error from restoring a backup on a recovery machine.
I got error about the max_connections that I changed from 350 to 100.
in the control file the value is 350
/usr/pgsql-17/bin/pg_controldata -D /pgdata/pgsql/17/main/ | grep max_conn
max_connections setting: 350
That is the value registered from the primary. But the primary is not intended to be connected during this restore.
primary_conninfo is desactivated.
Is there a trick to change decrease this value and start the instance.
Thanks for your help
Fabrice
2026-03-02 11:14:30.353 CET [1620147]: [3-1] user=,db=,client=,application= LOG: starting PostgreSQL 17.7 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-11), 64-bit
2026-03-02 11:14:30.354 CET [1620147]: [4-1] user=,db=,client=,application= LOG: listening on IPv4 address "0.0.0.0", port 5432
2026-03-02 11:14:30.354 CET [1620147]: [5-1] user=,db=,client=,application= LOG: listening on IPv6 address "::", port 5432
2026-03-02 11:14:30.355 CET [1620147]: [6-1] user=,db=,client=,application= LOG: listening on Unix socket "/run/postgresql/.s.PGSQL.5432"
2026-03-02 11:14:30.357 CET [1620147]: [7-1] user=,db=,client=,application= LOG: listening on Unix socket "/tmp/.s.PGSQL.5432"
2026-03-02 11:14:30.362 CET [1620154]: [1-1] user=,db=,client=,application= LOG: database system was interrupted; last known up at 2026-02-25 18:00:01 CET
2026-03-02 11:14:30.362 CET [1620154]: [2-1] user=,db=,client=,application= LOG: creating missing WAL directory "pg_wal/summaries"
ERROR: The required file is not available: 0000000A.history
2026-03-02 11:14:31.415 CET [1620154]: [3-1] user=,db=,client=,application= LOG: starting backup recovery with redo LSN 3FB0/D9000028, checkpoint LSN 3FB0/D9010058, on timeline ID 9
2026-03-02 11:14:32.013 CET [1620154]: [4-1] user=,db=,client=,application= LOG: restored log file "00000009.history" from archive
2026-03-02 11:14:32.748 CET [1620154]: [5-1] user=,db=,client=,application= LOG: restored log file "0000000900003FB0000000D9" from archive
2026-03-02 11:14:32.749 CET [1620154]: [6-1] user=,db=,client=,application= LOG: starting point-in-time recovery to 2026-03-02 09:00:00+01
2026-03-02 11:14:32.760 CET [1620154]: [7-1] user=,db=,client=,application= LOG: recovered replication state of node 1 to 3FB0/D8D74100
2026-03-02 11:14:32.761 CET [1620154]: [8-1] user=,db=,client=,application= LOG: recovered replication state of node 2 to 3FB0/BB7C1518
2026-03-02 11:14:32.761 CET [1620154]: [9-1] user=,db=,client=,application= LOG: recovered replication state of node 3 to 3CBD/DDE26700
2026-03-02 11:14:32.761 CET [1620154]: [10-1] user=,db=,client=,application= FATAL: recovery aborted because of insufficient parameter settings
2026-03-02 11:14:32.761 CET [1620154]: [11-1] user=,db=,client=,application= DETAIL: max_connections = 100 is a lower setting than on the primary server, where its value was 350.
2026-03-02 11:14:32.761 CET [1620154]: [12-1] user=,db=,client=,application= HINT: You can restart the server after making the necessary configuration changes.
2026-03-02 11:14:32.762 CET [1620147]: [8-1] user=,db=,client=,application= LOG: startup process (PID 1620154) exited with exit code 1
2026-03-02 11:14:32.763 CET [1620147]: [9-1] user=,db=,client=,application= LOG: aborting startup due to startup process failure
2026-03-02 11:14:32.763 CET [1620147]: [10-1] user=,db=,client=,application= LOG: database system is shut down
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350
2026-03-02 10:27 problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350 Fabrice Chapuis <[email protected]>
@ 2026-03-02 14:36 ` Laurenz Albe <[email protected]>
2026-03-02 16:13 ` Re: problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350 Fabrice Chapuis <[email protected]>
1 sibling, 1 reply; 6+ messages in thread
From: Laurenz Albe @ 2026-03-02 14:36 UTC (permalink / raw)
To: Fabrice Chapuis <[email protected]>; Pgsql-admin <[email protected]>
On Mon, 2026-03-02 at 11:27 +0100, Fabrice Chapuis wrote:
> I got this error from restoring a backup on a recovery machine.
> I got error about the max_connections that I changed from 350 to 100.
> in the control file the value is 350
> /usr/pgsql-17/bin/pg_controldata -D /pgdata/pgsql/17/main/ | grep max_conn
> max_connections setting: 350
> That is the value registered from the primary. But the primary is not intended to be connected during this restore.
> primary_conninfo is desactivated.
>
> Is there a trick to change decrease this value and start the instance.
Why bother?
Leave max_connections at 350.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350
2026-03-02 10:27 problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350 Fabrice Chapuis <[email protected]>
2026-03-02 14:36 ` Re: problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350 Laurenz Albe <[email protected]>
@ 2026-03-02 16:13 ` Fabrice Chapuis <[email protected]>
2026-03-02 17:42 ` Re: problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350 Laurenz Albe <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Fabrice Chapuis @ 2026-03-02 16:13 UTC (permalink / raw)
To: Pgsql-admin <[email protected]>; Laurenz Albe <[email protected]>
Thanks for answering Laurenz,
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.
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.
These are the questions I've been asking to myself.
On Mon, Mar 2, 2026 at 4:20 PM Fabrice Chapuis <[email protected]>
wrote:
> Thanks for answering Laurenz,
>
> 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.
> 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.
>
> These are the questions I've been asking to myself.
>
> On Mon, Mar 2, 2026 at 3:36 PM Laurenz Albe <[email protected]>
> wrote:
>
>> On Mon, 2026-03-02 at 11:27 +0100, Fabrice Chapuis wrote:
>> > I got this error from restoring a backup on a recovery machine.
>> > I got error about the max_connections that I changed from 350 to 100.
>> > in the control file the value is 350
>> > /usr/pgsql-17/bin/pg_controldata -D /pgdata/pgsql/17/main/ | grep
>> max_conn
>> > max_connections setting: 350
>> > That is the value registered from the primary. But the primary is not
>> intended to be connected during this restore.
>> > primary_conninfo is desactivated.
>> >
>> > Is there a trick to change decrease this value and start the instance.
>>
>> Why bother?
>>
>> Leave max_connections at 350.
>>
>> Yours,
>> Laurenz Albe
>>
>
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350
2026-03-02 10:27 problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350 Fabrice Chapuis <[email protected]>
2026-03-02 14:36 ` Re: problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350 Laurenz Albe <[email protected]>
2026-03-02 16:13 ` Re: problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350 Fabrice Chapuis <[email protected]>
@ 2026-03-02 17:42 ` Laurenz Albe <[email protected]>
2026-03-03 08:27 ` Re: problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350 Fabrice Chapuis <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Laurenz Albe @ 2026-03-02 17:42 UTC (permalink / raw)
To: Fabrice Chapuis <[email protected]>; Pgsql-admin <[email protected]>
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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350
2026-03-02 10:27 problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350 Fabrice Chapuis <[email protected]>
2026-03-02 14:36 ` Re: problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350 Laurenz Albe <[email protected]>
2026-03-02 16:13 ` Re: problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350 Fabrice Chapuis <[email protected]>
2026-03-02 17:42 ` Re: problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350 Laurenz Albe <[email protected]>
@ 2026-03-03 08:27 ` Fabrice Chapuis <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Fabrice Chapuis @ 2026-03-03 08:27 UTC (permalink / raw)
To: Laurenz Albe <[email protected]>; +Cc: Pgsql-admin <[email protected]>
pooling is a good point.
Regards,
Fabrice
On Mon, Mar 2, 2026 at 6:42 PM Laurenz Albe <[email protected]>
wrote:
> 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
>
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-03-03 08:27 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-03-02 10:27 problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350 Fabrice Chapuis <[email protected]>
2026-03-02 11:05 ` AW: problem during postgres restore: max_connections = 100 is a lower setting than on the primary server, where its value was 350 Patolla Bernd <[email protected]>
2026-03-02 14:36 ` Laurenz Albe <[email protected]>
2026-03-02 16:13 ` Fabrice Chapuis <[email protected]>
2026-03-02 17:42 ` Laurenz Albe <[email protected]>
2026-03-03 08:27 ` Fabrice Chapuis <[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