On Wed, 2020-07-01 at 16:46 -0400, Stephen Frost wrote: > I continue to find it curious that we stress a great deal over (very > likely) poorly written backup scripts that haven't been updated in the > 5+? years since exclusive mode was deprecated, but we happily add new > keywords in new major versions and remove columns in our catalog tables > or rename columns or entirely redo how recovery works (breaking every > script out there that performed a restore..) or do any number of other > things that potentially break applications that communicate through the > PG protocol and other parts of the system that very likely have scripts > that were written to work with them. > > I'm really of the opinion that we need to stop doing that. > > If someone could explain what is so special about *this* part of the > system that we absolutely can't possibly accept any change that might > break user's scripts, and why it's worth all of the angst, maintenance, > ridiculously difficult documentation to understand and hacks (the > interface to pg_start_backup is ridiculously warty because of this), I'd > greatly appreciate it.
Easy. Lots of people write backup scripts, and fewer people write complicated pg_catalog queries. We would make way more users unhappy. Besides, there is nothing "poorly written" about a backup script using exclusive backup as long as the user is aware that there could be some small degree of trouble in case of a crash. You have a point about reworking the way recovery works: after teaching several classes and running into oddities with recovery parameters in postgresql.conf, I am not sure if that was a good move. Particularly the necessity for "recovery.signal" makes the New Way no easier than the Old Way - perhaps something like "pg_ctl start_in_recovery" would have been smarter. But one instance where we made users unhappy is not justification for making them unhappy again. Yours, Laurenz Albe