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.
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 |