On 12/11/18 11:31 PM, Robert Haas wrote: > On Wed, Dec 12, 2018 at 1:23 PM David Steele <da...@pgmasters.net> wrote: >> I didn't get the impression that Peter was against, he just thought that >> it needed to stand on its own, rather than be justified by the >> recovery.conf changes, which I agree with. >> >> Simon rather clearly said that he thinks we should wait until the next >> release, which I don't see as being entirely against. > > Well, nobody is saying that we should NEVER remove this. The > discussion is about what to do in v12.
Fair enough. > Most of the features I've been involved in removing have been > deprecated for 5+ years. The first release where this one was > deprecated was only 2 years ago. So it feels dramatically faster to > me than what I think we have typically done. I think this case is different because exclusive backups have known issues. I also think that having two similar but different methods stifles development in this area and makes the docs harder to improve. There's a lot of "if this then that else that" in the docs which make them hard to maintain and harder to read. Add the fact that we have *zero* tests for exclusive backups. I only had to refactor one exclusive backup in the tests and since it did not archive, exclude pg_wal, postmaster.pid, or do anything else our docs recommend I wouldn't say it qualifies as a real test. Also, it wasn't even trying to test exclusive backups -- it was a test for logical replication following timelines. So yeah, we'd be removing it in three years instead of five, but there has been a safe in-core alternative since 9.1 (eight years). Regards, -- -David da...@pgmasters.net
