James B. Byrne wrote:
Hi,
> 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
--create is not working here because you select a custom format for your
dump. --create is only working with plain SQL dumps.
> 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
with the --clean parameter you delete existing objects in hll_redmine
but there are dependant objects. A common way to avoid this is to drop
the whole database first, create a new one and then restore the dump
into it. Means use --create instead of --clean.
Dropping the database can cause problems because you have to cut all
client connections before being able to cut it. So maybe this approach
is not working for you.
Another idea is not to use any of these parameters and dump only the data.
pg_restore -a
Cheers Andy