PG_DUMP/RESTORE Would like an explanation of these (non-critical) errors

From: "James B(dot) Byrne" <byrnejb(at)harte-lyne(dot)ca>
To: pgsql-general(at)postgresql(dot)org
Subject: PG_DUMP/RESTORE Would like an explanation of these (non-critical) errors
Date: 2009-07-02 16:56:09
Message-ID: 43622.216.185.71.24.1246553769.squirrel@webmail.harte-lyne.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


I move a compressed pg_dump archives across the wire to a remote
host on a regular schedule. The process completes and the archives
are restored on the remote site and the resulting database performs
as expected.

However, I get this returned to me at the end of each
dump/transfer/restore

pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 4; 2615 2200 SCHEMA
public postgres
pg_restore: [archiver (db)] could not execute query: ERROR: cannot
drop
schema public because other objects depend on it
HINT: Use DROP ... CASCADE to drop the dependent objects too.
Command was: DROP SCHEMA public;
pg_restore: [archiver (db)] could not execute query: ERROR: schema
"public" already exists
Command was: CREATE SCHEMA public;
WARNING: errors ignored on restore: 2

The pg_dump command is:

pg_dump --create --format=c --user=postgres --verbose hll_redmine |
gzip > /var/data/pas-redmine/db/dump/hll_redmine.pgsql.gz && rsync
-avz --bwlimit=35 --delete-after --exclude="database.yml"
--exclude="*.log" --exclude="*cache" --exclude="*ruby_sess*"
/var/data/pas-redmine inet03.mississauga.harte-lyne.ca:/var/data 1>
/dev/null

The pg_restore command, which generates the error, is:

gunzip < /var/data/pas-redmine/db/dump/hll_redmine.pgsql.gz |
pg_restore --clean --user=postgres --dbname=hll_redmine ; vacuumdb
--user=postgres --full --analyze hll_redmine 1> /dev/null

I speculate that I have set some options on the restore that
conflict with those set on the dump, perhaps --create. Regrettably,
I lack the expertise to determine if this is the cause or not; and,
as this is a production environment, I lack the ability to play with
them to determine what is incorrect.

If anything is obviously wrong, or even mildly suspicious, I would
appreciate a nudge in the right direction. This issue at least has
no overlong dates.

--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB(at)Harte-Lyne(dot)ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Brandon Metcalf 2009-07-02 17:27:48 simulate multiple primary keys
Previous Message Tom Lane 2009-07-02 16:49:36 Re: compiling postgres for 64 bit windows using mingw64