On 11/27/18 3:59 AM, Peter Eisentraut wrote:
> On 25/11/2018 21:39, Andres Freund wrote:
>> On 2018-11-25 13:24:15 -0500, Stephen Frost wrote:
>>> - User performs a backup with pg_basebackup -R
>>> - Replica is then promoted to be a primary
>>> - User performs a backup with pg_basebackup -R on the new primary
>>> - Duplicate entries end up in postgresql.auto.conf. Ew.
>> Why don't we put recovery entries into postgresql.recovery.conf or such?
>> And overwrite rather than append?
>
> Adding more such sub-configuration files would be easy to do and has
> some merit, but the devil is in the details. In what order would those
> files be read? Who is supposed to write to it, is it reserved for
> pg_basebackup use only? If you choose to use this particular name, is
> it not used when not in recovery? Does this file belong in the data
> directory or the configuration directory? Which choice will offend
> packagers the least? Etc.
I would prefer a specific file that will be auto-included into
postgresql.conf when present but be ignored when not present. Some
settings are generally ephemeral (recovery_target_time) and it would be
nice for them to go away. When recovery is complete the file would be
renamed to .done just as recovery.conf is now.
I had been thinking about keeping the recovery.conf file name but on
reflection is seems best to make a clean break. I like Andres'
suggestion of postgresql.recovery.conf.
I would not be in favor of this file being for pg_basebackup only. If
it has documented and consistent behavior then any restore solution
should be able to use it.
To be clear, the aim is to give tools a place to write recovery GUCs
that are considered temporary and/or replaceable. Users are still free
to write permanent recovery GUCs into whatever file they would like,
e.g. restore_command.
Regards,
--
-David
david@pgmasters.net