On Thu, May 26, 2016 at 2:48 PM, Ken Winter <ken@sunward.org> wrote:
I just discovered that a run of pg_dump that gets aborted empties any pre-existing backup file of the same name. It happens whether the run was deliberately canceled by the user or just failed because of a bad password (as in the example below).
~/dba$ ls -l mess_development.bak -rw-rw-r-- 1 ken ken 87070 May 26 14:20 mess_development.bak
~/dba$ pg_dump --host=localhost -U ken --format=c --file=mess_development.bak --no-owner --no-privileges mess_development Password: <BAD PASSWORD ENTERED> pg_dump: [archiver (db)] connection to database "mess_development" failed: FATAL: password authentication failed for user "ken" FATAL: password authentication failed for user "ken"
~/dba$ ls -l mess_development.bak -rw-rw-r-- 1 ken ken 0 May 26 14:21 mess_development.bak
~/dba$
This is troubling because I can imagine a disaster scenario where one loses one's previous backup and, perhaps because of a forgotten password, can't generate a new one. (This scenario hasn't happened to me yet, but seems like it could.) In general, a failed run of a piece of software should leave everything unchanged. So maybe this is a bug that needs to be fixed?
~ Ken
>...a run of pg_dump that gets aborted empties any pre-existing backup file of the same name
This is standard behavior. By using the same output file name, you are telling the O/S to overwrite/delete that file and replace with new information.
Most DBA's usually specify a date(and/or time) as a suffix to prevent that probleb and keep several versions of backup.
Not that it in this case, but it is considered good procedure to report the PostgreSQL version and O/S when contacting this list for support.
Please consider that for future correspondence.
--
Melvin Davidson I reserve the right to fantasize. Whether or not you wish to share my fantasy is entirely up to you.