Re: [COMMITTERS] pgsql: Allow external recovery_config_directory
От | Heikki Linnakangas |
---|---|
Тема | Re: [COMMITTERS] pgsql: Allow external recovery_config_directory |
Дата | |
Msg-id | 5152F778.2070205@vmware.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Allow external recovery_config_directory (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: [COMMITTERS] pgsql: Allow external recovery_config_directory
|
Список | pgsql-hackers |
On 27.03.2013 15:11, Simon Riggs wrote: > On 27 March 2013 12:59, Michael Paquier<michael.paquier@gmail.com> wrote: > >> Also, based on Greg's spec (that Robert and I basically agreed on), if >> recovery.conf is found at the root of data folder an error is returned to >> user, recommending him to migrate correctly by referring to dedicated >> documentation. > > I'm following what was agreed on 24 December. Well, there wasn't much discussion about it back then. The way I read the thread is that people agreed with the general approach, as now implemented in Michael's patch, based on Fujii's earlier patch. This might be a good idea or not, but it's a new and separate feature, not related to whatever else we might do with recovery.conf. If we are to discuss the merits of this patch now, a few thoughts: 1. This is going to make life more complicated for tools that want to mess with recovery.conf, as it's no longer guaranteed to be in $PGDATA. 2. An admin can no longer tell if a server is in standby or PITR mode just by checking for $PGDATA/recovery.conf 3. Would it make sense to make the option "recovery_config_file", pointing to the file, instead of just the directory? 4. Could you achieve the same with a symlink in $PGDATA? > We can have the whole debate again, if you wish. There is no reason to > break backwards compatibility to get what we want. AFAICS this is completely orthogonal to backwards-compatibility and other aspects of the upcoming patch to merge recovery.conf and postgresql.conf. - Heikki
В списке pgsql-hackers по дате отправления: