Re: pg_restore fails

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: pg_restore fails
Date: 2016-03-13 01:59:55
Message-ID: CAKFQuwZwH=o=xHWHL02_7CYrXV9h7uXWn+3hG1uvg5kT15us_g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Saturday, March 12, 2016, Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>
wrote:

> On Sat, Mar 12, 2016 at 05:49:56PM -0700, David G. Johnston wrote:
>
> > 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.
>
> --exit-on-error will exit on _any_ perceived error,
> regardless of whether it could be ignored and the restore
> still succeed later on. Hence I cannot keep that option in
> use in order to implement the below.
>
> The unfortunate thing is that *any* restore will "fail"
> because the schema PUBLIC is copied from the template and
> that alone will produce an (ignorable) error...
>
>
So you make things so that error doesn't occur, the work-arounds are
reasonably simple.

Using either clean or create alone succeeded without the public schema
error. It is only when you use both will it fail. But both those
individual options have pre-reqs you need to ensure are met before calling
pg_restore.

David J.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Melvin Davidson 2016-03-13 02:19:11 Re: Distributed Table Partitioning
Previous Message Alvaro Aguayo Garcia-Rada 2016-03-13 01:33:59 Re: Distributed Table Partitioning