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.
Related
When I try to restore my database backup, I am getting following error.
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 214; 1259 32064 TABLE country_amd0 userldd
pg_restore: [archiver (db)] could not execute query: ERROR: role "userldd" does not exist
Command was: ALTER TABLE country_amd0 OWNER TO userldd;
Does anybody know what this error is about?
Thank You.
A custom-format dump is just of the database its self, not the global state like users.
If you don't have a pg_dump --globals-only too, you will need to re-create any:
roles (users/groups)
tablespaces
and other global objects referenced by the dump.
It's a shame that pg_dump doesn't auto-include those if referenced by the dump, so you could optionally restore them too. A patch for this would be very welcome, but so far nobody's stepped up.
I'm unable to restore my backup DB on heroku DB but I don't have any issue if I restore on my local env and I get no errors.
When I try to restore on heroku connect database I get this following error:
C:\Program Files\PostgreSQL\9.4\bin\pg_restore.exe --host
XXXXXX.compute-1.amazonaws.com --port 5432 --username
"XXXXokwpyzewicl" --dbname "d9uto7paqXXX" --no-password --verbose
"C:\Users\XXXX\Desktop\loans.backup"
pg_restore: connecting to
database for restore pg_restore: implied data-only restore
pg_restore: processing data for table "application_denial_reason_types"
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 5202; 0 16622 TABLE DATA application_denial_reason_types postgres
pg_restore: [archiver (db)] could not execute query: ERROR: relation "application_denial_reason_types" does not exist
Command was: COPY application_denial_reason_types (denial_reason_type_id, denial_reason_type_name, description, active, created_by, creat... pg_restore: executing SEQUENCE SET application_denial_reason_types_denial_reason_type_id_seq
pg_restore: [archiver (db)] Error from TOC entry 5672; 0 0 SEQUENCE SET
application_denial_reason_types_denial_reason_type_id_seq postgres
pg_restore: [archiver (db)] could not execute query: ERROR: relation
"application_denial_reason_types_denial_reason_type_id_seq" does not
exist LINE 1: SELECT pg_catalog.setval('application_denial_reason_types_de...
^
Command was: SELECT pg_catalog.setval('application_denial_reason_types_denial_reason_type_id_seq',
1, false);
How do I fix this error?
It tries to set value of not existing sequence:
pg_restore: [archiver (db)] could not execute query: ERROR: relation
"application_denial_reason_types_denial_reason_type_id_seq" does not
exist
to understand the reason take alook at the:
pg_restore: connecting to database for restore pg_restore: implied
data-only restore
If you check man pg_restore you'll find, that:
-a
--data-only
Restore only the data, not the schema (data definitions). Table data, large objects, and sequence values are restored, if
present in the archive.
So you probably have data structure on your local env, and this is why you set value for existing sequence. And there is not structure on heroku, so you get error.
Remove -a from pg_restore command to run DDL prior to data restore.
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 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.