Joshua D. Drake <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers