On Thu, Feb 3, 2022 at 3:17 PM Julien Rouhaud <rjuju123@xxxxxxxxx> wrote: > > Hi, > > On Thu, Feb 03, 2022 at 10:36:37AM +0100, Luca Ferrari wrote: > > Hi all, > > running PostgreSQL 14, physical replication with slot, after changing > > (increasing) the max_connections on the primary, I had this message at > > a restart from the standby: > > > > DETAIL: max_connections = 100 is a lower setting than on the primary > > server, where its value was 300. > > > > and the standby does not start until I raise also its max_connections. > > Why is PostgreSQL requiring the max_connections to be aligned between > > the primary and the standby? > > The value needs to be at least equal as the value on the primary node, but it > can be bigger. > > That's because the standby needs to have enough resources to replay the > activity from the primary, including some heavyweight locks acquisition, and > the number of locks you can hold at one time is partially based on > max_connections. Agree that the standby should atleast have the capacity that the primary has in terms of resources. But what I don't like about that code is calling RecoveryRequiresIntParameter for each parameter separately and crashing the server FATALly for each insufficient parameter. Imagine if all the parameters were set to insufficient values on the standby and users keep setting the reported parameter to the right value and restart the server. At max, 5 FATAL failure-set right value-restart have to be performed. Instead, it would be better if the server emits a single log with all the insufficient parameters(max_connections, max_worker_processes, max_wal_senders, max_prepared_transactions and max_locks_per_transaction) values and crashes FATALly. The users can look at the logs at once, set all the insufficient parameters to right values and restart the server. Regards, Bharath Rupireddy.
