On 12/11/18 11:31 PM, Robert Haas wrote:
> On Wed, Dec 12, 2018 at 1:23 PM David Steele <david@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
david@pgmasters.net