I have dumped an OpenERP DB like this:
pg_dump -Fc -xO -f o7db.dump o7db
The source machine has:
$ pg_dump --version
pg_dump (PostgreSQL) 9.3.5
The I scp the dump to a target machine (an OpenVZ container), where pg_restore is:
$ pg_restore --version
pg_restore (PostgreSQL) 9.3.5
I run pg_restore like this:
pg_restore -d o7db -xO -j3 o7db.dump
The only difference I can see is that postgres user is not the same in both
machines (but that is supposed to be dealt by -O). pg_restore complains
about:
pg_restore: [archiver (db)] Error from TOC entry 8561; 0 1161831 TABLE DATA account_move_line manu
pg_restore: [archiver (db)] COPY failed for table "account_move_line": ERROR: value too long for type character varying(64)
CONTEXT: COPY account_move_line, line 172, column name: "<MASKED DATA HERE....>"
This error is issued several times for several tables. After that, many so
errors about missing tuples follow:
pg_restore: [archiver (db)] Error from TOC entry 6784; 2606 1182924 FK CONSTRAINT account_account_currency_id_fkey manu
pg_restore: [archiver (db)] could not execute query: ERROR: insert or update on table "account_account" violates foreign key constraint "account_account_currency_id_fkey"
DETAIL: Key (currency_id)=(1) is not present in table "res_currency".
Command was: ALTER TABLE ONLY account_account
ADD CONSTRAINT account_account_currency_id_fkey FOREIGN KEY (currency_id) REFERENCES re..
I don't see how this is possible, since the source DB seems to be Ok.
The restored DB has many empty tables (each that failed cause too long
values):
$ psql -d o7db -Ac "select * from account_move_line" | tail -1
(0 rows)
Furthermore, I do the pg_restore on the same source machine:
pg_restore -d o7db_restore -xO -j3 o7db.dump
Everything works as expected. Not a single warning.
What should I do? What am I doing wrong?
The answer is actually given in Moving PostgreSQL database fails on non-ascii characters with 'value too long'
It seems the target server creates DB with a different encoding, so creating the DB with UTF8 before restoring solves the problem.
Credit goes to #habe (https://stackoverflow.com/users/216458/habe)
So, I have voted my question to be closed.
Related
I am trying to restore a database from server using following to backup :
pg_dump --host=HOSTNAME --port=PORT --username=super --format=c --file=data.dump mydb
and this command to restore
psql -U postgres -h localhost -d test_db < datad.dump --no-privileges --no-owner
It's restoring the database's some part and data stored in test_db before also exits they don't get wiped.
EDIT:
These are the errors which get while pg_restore:
pg_restore: [archiver (db)] Error from TOC entry 3152; 2606 24665 FK CONSTRAINT django_admin_log_user_id_c564eba6_fk_accounts_user_id myadminuser
pg_restore: [archiver (db)] could not execute query: ERROR: constraint "django_admin_log_user_id_c564eba6_fk_accounts_user_id" for relation "django_admin_log" already exists
Command was: ALTER TABLE ONLY django_admin_log
ADD CONSTRAINT django_admin_log_user_id_c564eba6_fk_accounts_user_id FOREIGN KEY (user_id) REFERENCES accounts_user(id) DEFERRABLE INITIALLY DEFERRED;
WARNING: errors ignored on restore: 177
I'm trying to restore a table in a db in postgres from a .sql file.
I used command pg_restore -d dbName file.sql. The user is a superuser. But I got several errors:
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 359; 1259 499945 TABLE fuller4t7 someName
pg_restore: [archiver (db)] could not execute query: ERROR: permission denied to create "pg_catalog.fuller4t7"
DETAIL: System catalog modifications are currently disallowed.
Command was: CREATE TABLE fuller4t7 (
gid integer NOT NULL,
geom public.geometry(MultiPolygon,4326)
);
Other errors are related with this one since the table was not created in the first place. I'm wondering what these errors mean. I'm using postgres 9.4 and I have PostGIS extensions added to the particular database.
When restoring a dump like this:
pg_restore --clean --create --exit-on-error --dbname=test test.tar
these error messages got printed out:
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 21; 2615 80924 SCHEMA test test
pg_restore: [archiver (db)] could not execute query: ERROR: schema "test" already exists
Command was: CREATE SCHEMA test;
but when:
select schema_name from information_schema.schemata;
these got printed out
schema_name
--------------------
pg_toast
pg_temp_1
pg_toast_temp_1
pg_catalog
public
information_schema
It seems like schema "test" doesn't exist yet,why do I got this kind of error?
What OS, which version of postgres dump was made, restored to same version?
Read this article, maybe it will help.
It states that there are some trivial issues with the --clean parameter,
and you probably should try to create database manually and restore to it without
the create and clean options.
I've pored through the documentation of pg_dump and pg_restore and haven't found anything that would indicate that the custom format is more restrictive in some way. In fact, everything seems to indicate the opposite.
I'm running pg_dump like:
pg_dump --host=example.com --username=xxx --dbname=xxx \
--format=plain --table=ns_* --data-only > dump
And restoring that with:
cat dump | psql --host=example.com --username=xxx --dbname=xxx
And that that works fine. No errors and the data looks completely as expected. But if I change pg_dump to use the custom syntax like so:
pg_dump --host=example.com --username=xxx --dbname=xxx \
--format=custom --table=ns_* --data-only > dump
And then restore with:
pg_restore --host=example.com --username=xxx --dbname=xxx \
--data-only --single-transaction dump
I get the error:
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 2210; 0 1440417 TABLE DATA <table_name> <database_name>
pg_restore: [archiver (db)] COPY failed for table "<table_name>": ERROR: duplicate key value violates unique constraint "<table_name>_pkey"
DETAIL: Key (ex_id)=(7) already exists.
CONTEXT: COPY <table_name>, line 1
I don't see why this error occurs. First and foremost, it doesn't make any sense because there's obviously no duplicate key, otherwise the regular insertion would have failed (and manual inspection confirms this).
The database I'm inserting into is empty. It's been initialized with the schema (same schema that we're dumping from) and that's it.
Perhaps of note is that the primary keys have been modified in the past. They were all incremented by a set number, which required removing the primary key constraint temporarily. But this shouldn't invalidate the data (and the fact that the plain text format works shows the data is valid).
I'm using the pg:transfer utility recommended by Heroku to push and pull databases. For example:
heroku pg:transfer -f postgres://username:password#localhost/database-name -t postgres://user-name:password#host-name/database-name --confirm app-name
I have been able to do it successfully, but each time it states that error were ignored at the end of the transfer:
WARNING: errors ignored on restore: 59
Do I need to worry about this?
EDIT:
I went through my output and it seems to error on each table. It seems to drop the sequence, and then throw an error saying it does not exist.
pg_restore: dropping SEQUENCE OWNED BY roles_id_seq
pg_restore: dropping SEQUENCE roles_id_seq
pg_restore: [archiver (db)] Error from TOC entry 170; 1259 35485 SEQUENCE roles_id_seq postgres
pg_restore: [archiver (db)] could not execute query: ERROR: sequence "roles_id_seq" does not exist Command was: DROP SEQUENCE public.roles_id_seq;
My guess is that what is happening is that it is running a "clean" restore which means it drops the previous objects just to be sure and then recreates them.
If these are your only errors they are entirely safe to ignore. Too bad the toolchain is not smart enough to add an IF EXISTS to the drop commands.