Re: unite recovery.conf and postgresql.conf

On Fri, Sep 9, 2011 at 8:27 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>>> If the same parameter is specified in both file, the setting in recovery.conf
>>>> overrides that in postgresql.conf. In this case, SHOW command displays
>>>> the settings in postgresql.conf even though they are not used at all. Even if
>>>
>>> Now, *that* is just broken, IMHO. The SHOW command should show what is
>>> actually in use, period. Everything is guaranteed to confuse the hell
>>> out of anybody trying to use it.
>>
>> I'm afraid that we have to add very complicated code to fix that problem.
>> Though of course we can easily fix the problem if we don't care about
>> the backward compatibility.
>
> That is an even bigger reason to drop backwards compatibility. Unless
> someone else can come up with a neat way of fixing it.

Agreed. After a little thought, it's came to mind that we might be
able to simply
fix that problem by making the postmaster instead of the startup process read
recovery.conf; The postmaster reads recovery.conf before it invokes the startup
process, and sets the global variables of GUC to the specified values. The child
processes including the startup process inherit the global variables of GUC, so
SHOW can return the exact setting value and the startup process can use them
to do a recovery. Even in EXEC_BACKEND case, we can adopt this idea because
those global variables are inherited from parent to children via the
save/restore_backend_variables functions.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center