| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Cc: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>, Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de>, Kaijiang Chen <chenkaijiang(at)gmail(dot)com>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: pg_dump's results have quite different size |
| Date: | 2016-12-16 21:32:29 |
| Message-ID: | CAKFQuwa7ZVH1wje55m7H6okvtKMceuE=OiAfg1-gugxSEEFT2g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, Dec 16, 2016 at 1:47 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> The only thing we actually know with reasonable certainty is that his
> backup script is broken, and that this is bad. Randomly changing settings
> so that the brokenness is still there but just less obvious is more
> dangerous than helpful.
>
>
Its been suggested before but pg_dump could be a bit more helpful if it
dumped contents to a temporary location first and then, if the dump
completes successfully, moves it to the user-specified location. It would
be a bit of a subtle error if the dump fails silently and the user doesn't
notice that the timestamp of an already existing dump at the named location
didn't change - but if the target location is already unoccupied then the
absence of a file would be very obvious.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Kirkwood | 2016-12-16 22:30:31 | Re: pg_dump's results have quite different size |
| Previous Message | Jeff Janes | 2016-12-16 20:47:03 | Re: pg_dump's results have quite different size |