I hear that createdb is better to run against live a database instead of pg_restore.. I have this command:
PGPASSWORD="$db_pwd" createdb -U "$db_user" -h "$db_host" -p 5432 --no-password -e "$db_name"
but I am getting this error:
SELECT pg_catalog.set_config('search_path', '', false)
CREATE DATABASE platform_production_backup_2;
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 4034; 0 0 COMMENT EXTENSION pg_trgm
pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of extension pg_trgm
Command was: COMMENT ON EXTENSION pg_trgm IS 'text similarity measurement and index searching based on trigrams';
so what does this error mean:
ERROR: must be owner of extension pg_trgm
? why is it trying to use the extension or copy it?
That error is harmless.
It means that you restored the dump as a user that is not a superuser, so you cannot set the comment on the (already existing) extension pg_trgm.
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 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.
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 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.