On 11/27/18 9:54 AM, Peter Eisentraut wrote:
> On 27/11/2018 15:45, Stephen Frost wrote:
>>>> But backup scripts are not affected by the recovery.conf changes.
>>> In any of my own backup scripts (yeah!), I don't have any dependency to
>>> that either. Or perhaps pgBackRest has a dependency in this area?
>> If you don't consider your recovery scripts and your backup scripts to
>> be related then I've really got to wonder how you're regularly testing
>> your backups to make sure that they're actually valid.
>
> The sort of installations that continue to use the exclusive backup mode
> probably have the following tooling: a 20-line shell script to make the
> backup and either a 10-line shell script or a similarly sized README or
> wiki page to do the recovery. Changing the latter for the recovery.conf
> changes is probably a 3-line change.
Really? We have gone from a file that can be safely overwritten
(recovery.conf) to a file that might need to be parsed to figure out if
the settings already exists (postgresql.auto.conf). Of course, you can
just continue to append to the file but that seems pretty grotty to me.
This will also require changes to all HA solutions or backup solutions
that deal with recovery. I think you underestimate how big a change
this is. I've been thinking about how to write code for it and it is
significantly more complex -- also more flexible so I'm happy about that.
> Changing the former for the
> removal of exclusive backups would require major changes. (Try writing
> a shell script that keeps a psql session open while it takes the backup
> from the file system. It's possible, but it requires significantly more
> logic.)
We provide pg_basebackup with core and it is a solid tool for doing
backups. Do we really want to encourage the use of bash scripts to do
what we already have a tool for? If users want to do something more
complex than pg_basebackup then bash is certainly not the tool for that.
Regards,
--
-David
david@pgmasters.net