tomek wrote
> The following bug has been logged on the website:
>
> Bug reference: 11991
> Logged by: Tomasz Kimaczynski
> Email address:
> tomek@
> PostgreSQL version: 9.2.9
> Operating system: Windows 2003,2008,2012 & FreeBSD
> Description:
>
> Recently, I realized pg_dump dangerous activity. In case when no dump is
> made because of any error, created file size is 0 bytes. In case when this
> file is used in simple backup procedure which make copy of dump file - 0
> bytes files overwrite earlier correct dump files.
> And we have no copies.
> Conclusion: pg_dump can not create 0 bytes files - it should create
> nothing.
> I think it's important.
Even if this were to be done there are other failure modes that will result
in partial dumps. The correct answer is to always keep the last correct
dump until the next successful dump completes. This is a minimum acceptable
practice.
Tools can make your life easier but this special case is more likely to do
harm than good if people test a quick fail mode and see their original file
remain when it should be clobbered. If anything pg_dump should error if the
target dump file already exists.
If you are talking about your own copy process than that is your
responsibility. Copying files without even rudimentary checks that the
dumped file is complete is simply being negligent. In theory you should
restore the file and run some queries before declaring it good but at
minimum file size and program return code checks are needed. Specifically
if the dump file is considerably smaller than previous versions you should
not remove the old version automatically. Zero always qualifies but even
100 meg decrease should give pause and prompt human evaluation.
David J.
--
View this message in context: http://postgresql.nabble.com/BUG-11991-dangerous-action-of-pg-dump-tp5827321p5827327.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.