Joshua D. Drake <jd@commandprompt.com> wrote:
> PITR is wonderful, I use it all the time. It has exactly zero to
> do with what we are talking about. We are talking about pg_dump
> and its usefulness. Are you suggesting that we tell people to not
> use pg_dump and instead use PITR?
Yes. (Well, actually, any of the WAL-based techniques.) pg_dump
is not a good tool for primary backups, for many reasons. At least
on databases over 50GB or so or which have more than a few data
modifications per second. It is OK on a tiny 10GB database with
daily (or less frequent) batch modifications, but how often do you
see something like that?
> This is about production DBA/admins, the 98% of people using
> postgresql.
That is who I am thinking of. A DBA team may have hundreds of
databases to manage, each with many scripts which have been running
nicely for years. A change like this is bound to break some of
those crontab scripts they may not even remember they are running
-- like ones which dump a key table to INSERT statements to feed
into some other database product, which will now choke when it gets
a custom format file instead of the text file it has been getting
for years. Requiring the DBA team to track all these scripts down
to add -Fp would be annoying, to put it mildly.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company