Re: pg_restore fails

On Sat, Mar 12, 2016 at 5:43 PM, Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>
wrote:

> On Sat, Mar 12, 2016 at 05:31:38PM -0700, David G. Johnston wrote:
>
> > > The reason being, of course, that I want to check the exit
> > > code in a pg_restore wrapper script.
> > >
> > >
> > I mistakenly thought public only came from template1...I wouldn't be
> > opposed to that change. This all seems awfully familiar too...
> >
> > You probably should just drop the existing database and use --create by
> > itself.
> >
> > You can even use the dropdb command to avoid SQL in your script.
>
> I already do something similar: the wrapper fails if the
> target db exists before a restore is even attempted. The
> restore itself now uses --create and works as expected. The
> only thing left ATM is that I cannot distinguish
> success-with-or-without-ignored-errors from real failure.
>
> I _can_ partly work around that by attempting to connect to
> the target and checking the md5 sum of the schema definition
> against a known hash. That won't help with detecting whether
> pg_restore thought that _data_ was successfully restored ...
>
>
​I'd operate under the premise that all warnings and errors are fatal
(i.e., keep --exit-on-error) until you cannot for some very specific
reason. I'd decide how to proceed at that point. For instance pg_restore
does provide an ignored error count at the end - you could scan the log for
expected errors, count them, and compare to that value and fail if the
count differs.
​ But this particular warning should be easy to work around and you
shouldn't expect any others that would be considered non-critical.

David J.