Hi Andres,
On 2/25/19 10:57 PM, Andres Freund wrote:
> Hi,
>
> On 2019-02-25 08:14:16 -0500, Stephen Frost wrote:
>>> It will be annoying if after this removal, companies must change their
>>> backup strategy by using specific postgres tools (pgbackrest, barman).
>>
>> You don't write your own database system using CSV files and shell
>> magic, do you? I have to say that it continues to boggle my mind that
>> people insist that *this* part of the system has to be able to be
>> implementable using shell scripts.
>>
>> Folks, these are your backups we're talking about, your last resort if
>> everything else goes up in flames, why do you want to risk that by
>> implementing your own one-off solution, particularly when there's known
>> serious issues using that interface, and you want to just use shell
>> scripts to do it...?
>
> FWIW, if you weren't selling backrest quite so hard everywhere backups
> are mentioned, I'd find this thread a lot more convicing.
pgBackRest has not used exclusive backups since the new API was
introduced in 9.6 so this is not an issue for our users.
Over time we have contributed back to Postgres in areas we thought could
be improved based on our work on the pgBackRest project: 6ad8ac60,
9fe3c644, 017e4f25, 78874531, 449338cc, 98267ee8, 8694cc96, 920a5e50,
c37b3d08, 5fc1670b, b981df4c. This does not include the various backup
related patches that we have reviewed.
If promoting pgBackRest were our primary concern then it would be in our
interest to allow Postgres exclusive backups to stay broken and
pg_basebackup to be as primitive as possible.
Our objections to exclusive backups stem from a desire to do the right
thing, as we see it, and because we have seen first hand all the ways
that backups can go wrong.
--
-David
david@pgmasters.net