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
da...@pgmasters.net
