On Sat, Oct 29, 2011 at 7:54 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On Fri, Sep 9, 2011 at 10:56 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > >> In previous discussion, we've reached the consensus that we should unite >> recovery.conf and postgresql.conf. The attached patch does that. The >> patch is WIP, I'll have to update the document, but if you notice something, >> please feel free to comment. > > My short summary of the thread is
Thanks! > In 9.1 we added "pg_ctl promote" as a better way of indicating > failover/switchover. When we did that we kept the trigger_file > parameter added in 9.0, which shows it is possible to add a new API > without breaking backwards compatibility. > > We should add a "pg_ctl standby" command as a better way of indicating > starting up (also described as triggering) standby mode. We keep > standby_mode parameter. There is no difference here between file > based and stream based replication: you can have file, stream or both > file and stream (as intended). > In this mode the recovery target parameters are *ignored* even if > specified (explained below). > http://developer.postgresql.org/pgdocs/postgres/recovery-target-settings.html Agreed to add "pg_ctl standby". I think that this can be committed separately from the change of recovery.conf. > In 9.2 the presence of recovery.conf can and therefore should continue > to act as it does in 9.1. This means that recovery.conf is renamed to recovery.done at the end of recovery. IOW, all settings in recovery.conf are reset when recovery ends. Then if you run "pg_ctl reload" after recovery, you'll get something like the following error message and the reload will always fail; LOG: parameter "standby_mode" cannot be changed without restarting the server To resolve this issue, I think that we need to introduce new GUC flag indicating parameters are used only during recovery, and need to define recovery parameters with that flag. Whenever "pg_ctl reload" is executed, all the processes check whether recovery is in progress, and ignore silently the parameters with that flag if not. I'm not sure how easy we can implement this. In addition to introducing that flag, we might need to change some processes which cannot access to the shared memory so that they can. Otherwise, they cannot know whether recovery is in progress. Or we might need to change them so that they always ignore recovery parameters. Another simple but somewhat restricted approach is to read and set all parameters specified in recovery.conf by using PGC_S_OVERRIDE. If we do this, those parameters cannot be changed after startup even if recovery.conf is renamed. But the problem is that a user also cannot change their settings by reloading the configuration files. This is obviously a restriction. But it doesn't break any backward compatibility, I believe. No? If a user prefers new functionality (i.e., reload recovery parameters) rather than the backward compatibility, he/she can specify parameters in postgresql.conf. Thought? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers