From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Subject: | Re: Proposal for changes to recovery.conf API |
Date: | 2016-09-06 08:12:18 |
Message-ID: | CANP8+jKF7nWypEzjcG7Ujrxgjzfjhte2P0CaVuK6q8PZkeL1Ww@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6 September 2016 at 08:06, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com> wrote:
> At 2016-09-06 14:40:54 +0900, michael(dot)paquier(at)gmail(dot)com wrote:
>>
>> my best advice here is to make all those recovery_target_* parameters
>> PGC_POSTMASTER so as they are loaded only once when the server starts,
>> and then we define the recovery target type used in the startup
>> process instead of trying to do so at GUC level.
>
> I understand your approach in light of the GUC code, but I see things a
> bit differently—the complexity comes largely from the specific handling
> of recovery_target. I'll try to come up with a way to do it better. If
> not, we have your suggestion to fall back on.
As I said upthread...
"We definitely want most of them set at RELOAD, especially recovery targets."
So PGC_POSTMASTER is not the objective.
How then to proceed?
I guess we could keep the old parameters and make them PGC_POSTMASTER,
but also provide a new parameter called recovery_target that
simplifies the API and is PGC_SIGHUP. That way we resolve the
annoyance of handling the current ones but keep compatibility for
those who can't move on, just yet.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Aleksander Alekseev | 2016-09-06 08:20:27 | Re: Suggestions for first contribution? |
Previous Message | Daniel Verite | 2016-09-06 08:10:08 | Re: PATCH: Batch/pipelining support for libpq |