Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file
Chapman Flack <chap@anastigmatix.net>
From: Chapman Flack <chap@anastigmatix.net>
To: Stephen Frost <sfrost@snowman.net>
Cc: David Steele <david@pgmasters.net>,
Nathan Bossart <nathandbossart@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2022-03-01T19:56:12Z
Lists: pgsql-hackers
On 03/01/22 14:14, Stephen Frost wrote: >> There can't really be many teams out there thinking "we'll just ignore >> these scripts forever, and nothing bad will happen." They all know they'll >> have to do stuff sometimes. But it matters how we allow them to schedule it. > > We only make these changes between major versions. That's as much as we > should be required to provide. It's an OSS project, so I guess we're not required to provide anything. But in the course of this multi-release exclusive to non-exclusive transition, we already demonstrated, in 7117685, that we can avoid inflicting immediate breakage when there's nothing in our objective that inherently requires it, and avoiding it is relatively easy. I can't bring myself to think that was a bad precedent. Now, granted, the difference between the adaptations being required then and the ones required now is that those required both: changes to some function calls, and corresponding changes to how the scripts handled label and tablespace files. Here, it's only a clerical update to some function calls. So if I'm outvoted here and the reason is "look, a lighter burden is involved this time than that time", then ok. I would rather bow to that argument on the specific facts of one case than abandon the precedent from 7117685 generally. Regards, -Chap
Commits
-
Remove duplicated word in comment of basebackup.c
- 83cca409edf2 15.0 landed