From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | Luca Ferrari <fluca1978(at)gmail(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: max_connections different between primary and standby: is it possible? |
Date: | 2022-02-03 14:19:37 |
Message-ID: | 20220203141937.adnbceyimpj44d6l@jrouhaud |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Feb 03, 2022 at 05:39:57PM +0530, Bharath Rupireddy wrote:
>
> 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
Sure, but one failed start / inspect logs / modify configuration / start will
always by longer than just reading the docs and making sure that the
configuration is appropriate. It also won't help if you want to modify the
settings on your primary and make sure that you won't have an incident on your
HA setup.
From | Date | Subject | |
---|---|---|---|
Next Message | Rama Krishnan | 2022-02-03 14:54:10 | Oracle to postgresql migration |
Previous Message | David G. Johnston | 2022-02-03 13:00:49 | Re: Can Postgres beat Oracle for regexp_count? |