Hi Karsten..
On Sun, Mar 13, 2016 at 12:09 AM, Karsten Hilbert
wrote:
> I am trying to pg_restore from a directory dump.
> However, despite using
>
> --clean
> --create
> --if-exists
>
> I am getting an error because schema PUBLIC already exists.
snip, snip
Have y
On Saturday, March 12, 2016, Karsten Hilbert
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-er
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 c
On Sat, Mar 12, 2016 at 5:43 PM, Karsten Hilbert
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 tem
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 awfull
On Sat, Mar 12, 2016 at 5:31 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> 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.
>
>
This seems like it is the main problem:
# dropdb po
On Saturday, March 12, 2016, Karsten Hilbert
wrote:
> On Sat, Mar 12, 2016 at 04:53:20PM -0700, David G. Johnston wrote:
>
> > The docs could probably use improvement here - though I am inferring
> > behavior from description and not code.
> >
> > The create option tells restore that it is pointl
On Sat, Mar 12, 2016 at 04:53:20PM -0700, David G. Johnston wrote:
> The docs could probably use improvement here - though I am inferring
> behavior from description and not code.
>
> The create option tells restore that it is pointless to use conditions or
> actively drop objects since the newly
On Sat, Mar 12, 2016 at 4:32 PM, Adrian Klaver
wrote:
> On 03/12/2016 03:09 PM, Karsten Hilbert wrote:
>
>> Hi,
>>
>> Debian Stretch
>> PG 9.5.1
>>
>> I am trying to pg_restore from a directory dump.
>>
>> However, despite using
>>
>> --clean
>> --create
>>
On Sun, Mar 13, 2016 at 12:37:02AM +0100, Karsten Hilbert wrote:
> > > pg_restore: [Archivierer (DB)] Fehler in Phase PROCESSING TOC:
> > > pg_restore: [Archivierer (DB)] Fehler in Inhaltsverzeichniseintrag 8;
> > > 2615 2200 SCHEMA public postgres
> > > pg_restore: [Archivierer (DB)] could
On Saturday, March 12, 2016, Karsten Hilbert
wrote:
> Hi,
>
> Debian Stretch
> PG 9.5.1
>
> I am trying to pg_restore from a directory dump.
>
> However, despite using
>
> --clean
> --create
> --if-exists
>
> I am getting an error because schema PUBLIC alre
On Sat, Mar 12, 2016 at 03:32:15PM -0800, Adrian Klaver wrote:
> > pg_restore: [Archivierer (DB)] Fehler in Phase PROCESSING TOC:
> > pg_restore: [Archivierer (DB)] Fehler in Inhaltsverzeichniseintrag 8;
> > 2615 2200 SCHEMA public postgres
> > pg_restore: [Archivierer (DB)] could not
On 03/12/2016 03:09 PM, Karsten Hilbert wrote:
Hi,
Debian Stretch
PG 9.5.1
I am trying to pg_restore from a directory dump.
However, despite using
--clean
--create
--if-exists
I am getting an error because schema PUBLIC already exists.
That schema is,
On Sun, Mar 13, 2016 at 12:09:19AM +0100, Karsten Hilbert wrote:
In case it is needed:
> pg_restore: erstelle SCHEMA „public“
creating SCHEMA "public"
> pg_restore: [Archivierer (DB)] Fehler in Phase PROCESSING TOC:
Error in Phase ...
> pg_restore: [Archivier
I believe our BDR build was from before May so that further explains the
issue. Sounds like this will not be a problem in the future. Thanks for the
help.
On Mon, Sep 28, 2015 at 4:49 PM, Alvaro Herrera
wrote:
> Tom Lane wrote:
> > Thom Brown writes:
> > > On 28 September 2015 at 22:21, Spencer
Tom Lane wrote:
> Thom Brown writes:
> > On 28 September 2015 at 22:21, Spencer Gardner
> > wrote:
> >> Actually, yes. That's the reason for backing up. We had been playing with
> >> BDR on a custom build but have reverted to the stock Ubuntu build for the
> >> time being. So it sounds like the
Thom Brown writes:
> On 28 September 2015 at 22:21, Spencer Gardner
> wrote:
>> Actually, yes. That's the reason for backing up. We had been playing with
>> BDR on a custom build but have reverted to the stock Ubuntu build for the
>> time being. So it sounds like the issue is caused by dumping f
On 28 September 2015 at 22:21, Spencer Gardner wrote:
> Actually, yes. That's the reason for backing up. We had been playing with
> BDR on a custom build but have reverted to the stock Ubuntu build for the
> time being. So it sounds like the issue is caused by dumping from our custom
> BDR build.
Actually, yes. That's the reason for backing up. We had been playing with
BDR on a custom build but have reverted to the stock Ubuntu build for the
time being. So it sounds like the issue is caused by dumping from our
custom BDR build. It's not really a big issue - I've already rebuilt the
affected
On 28 September 2015 at 21:47, Tom Lane wrote:
> Spencer Gardner writes:
>> I'm transferring all of the databases on my old postgres server to a new
>> server. To do this I'm using pg_dump and then pg_restore:
>
>> pg_dump --host localhost --port 5432 --username "postgres" --format custom
>> --bl
Spencer Gardner writes:
> I'm transferring all of the databases on my old postgres server to a new
> server. To do this I'm using pg_dump and then pg_restore:
> pg_dump --host localhost --port 5432 --username "postgres" --format custom
> --blobs --file ~/backups/census.backup census
> --and then-
>>> 2.Our production PG version is 8.1.3. For some reasons it is not possible to
>> upgrade to the LATEST;
>>> I tested the libpq also on this version and it worked. Is it OK? I mean, did
>> it worked by chance or the library
>>> API & contracts didn't change between this version and latest?
>> No
Tom Tom wrote:
> Magnus Hagander wrote
>> Tom Lane wrote:
>>> =?us-ascii?Q?Tom=20Tom?= <[EMAIL PROTECTED]> writes:
Magnus Hagander wrote:
> Attached is a pg_restore.exe off CVS tip today, which should include the
> patch. Please try this one.
I tested the restore using the provide
Tom Tom wrote:
> Magnus Hagander wrote:
>> Tom Tom wrote:
Tom Tom wrote:
> Hello,
>
> We have a very strange problem when restoring a database on Windows XP.
> The PG version is 8.1.10
> The backup was made with the pg_dump on the same machine.
>
> pg_restore -F c -
Tom Tom wrote:
>> Tom Tom wrote:
>>> Hello,
>>>
>>> We have a very strange problem when restoring a database on Windows XP.
>>> The PG version is 8.1.10
>>> The backup was made with the pg_dump on the same machine.
>>>
>>> pg_restore -F c -h localhost -p 5432 -U postgres -d "configV3" -v
>> "c:\Sha
> Tom Tom wrote:
> > Hello,
> >
> > We have a very strange problem when restoring a database on Windows XP.
> > The PG version is 8.1.10
> > The backup was made with the pg_dump on the same machine.
> >
> > pg_restore -F c -h localhost -p 5432 -U postgres -d "configV3" -v
> "c:\Share\POSTGRES.bac
Tom Tom wrote:
> Hello,
>
> We have a very strange problem when restoring a database on Windows XP.
> The PG version is 8.1.10
> The backup was made with the pg_dump on the same machine.
>
> pg_restore -F c -h localhost -p 5432 -U postgres -d "configV3" -v
> "c:\Share\POSTGRES.backup"
> pg_resto
Stefan Schwarzer <[EMAIL PROTECTED]> writes:
> I just wanted to restore a dump which I did, which includes some
> postgis data. But, it doesn't work and instead I get this error message:
> pg_restore: restoring data for table "boundaries_national"
> pg_restore: [archiver (db)] error returned by P
28 matches
Mail list logo
