Re: [COMMITTERS] pgsql: Allow external recovery_config_directory
От | Tom Lane |
---|---|
Тема | Re: [COMMITTERS] pgsql: Allow external recovery_config_directory |
Дата | |
Msg-id | 15980.1364404983@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Allow external recovery_config_directory (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: [COMMITTERS] pgsql: Allow external recovery_config_directory
|
Список | pgsql-hackers |
Heikki Linnakangas <hlinnakangas@vmware.com> writes: > On 27.03.2013 18:10, Simon Riggs wrote: >> On 27 March 2013 15:35, Heikki Linnakangas<hlinnakangas@vmware.com> wrote: >>> Ok, cool. Can you please revert this commit so that we can move on, then? >> Please explain why you want this reverted, without mentioning the >> other task we agree is required. > If an admin can't trust that the file is placed in $PGDATA, it's harder > to determine if a server is a master or a standby. It makes tools that > try to promote / demote a server more complicated, because they need to > take this setting into account. Lastly, it breaks the new pg_basebackup > -R functionality; pg_basebackup will create the recovery.conf file, but > it won't take effect. FWIW, I agree that this is a bad idea and should be reverted. Simon is claiming that because he described this idea in one sentence (out of a larger post) three months ago, everyone agreed to the idea and there is no longer any room for discussion. In reality I suspect nobody really thought about the implications at the time. In any case, the arguments that have been made today seem to me to be sufficient reasons why we *don't* want to put recovery.conf in random places outside the data directory. regards, tom lane
В списке pgsql-hackers по дате отправления: