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 da...@pgmasters.net
