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.
Related
On a PostgreSQL instance of v10.21, we created appuser for the operations regarding the application, and we don't usually have the credential of the superuser postgres.
It seems that postgres owns the public schema inside any database by default, even if the database is created and owned by appuser. This system behaviour conflicts with pg_restore --clean.
The --clean option means to clean before restoring, so when the process comes to dropping the public schema, it encounters errors saying could not execute query: ERROR: must be owner of schema public. See more details in the screenshot below.
I am wondering:
As a quick dirty workaround, should we just ignore the errors?
Or, should we get the superuser to change the owner to appuser? This action will suppress the errors but we don't know whether there is any complication after changing the system's default settings.
Screenshot of pg_restore --clean run-time errors:
...
... dropping other objects in the public schema ...
...
pg_restore: dropping SEQUENCE OWNED BY activity_id_seq
pg_restore: dropping SEQUENCE activity_id_seq
pg_restore: dropping TABLE activity
pg_restore: dropping COMMENT SCHEMA public
pg_restore: dropping SCHEMA public
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 3; 2615 2200 SCHEMA public postgres
pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of schema public
Command was: DROP SCHEMA public;
pg_restore: creating SCHEMA "public"
pg_restore: [archiver (db)] could not execute query: ERROR: schema "public" already exists
Command was: CREATE SCHEMA public;
pg_restore: creating COMMENT "SCHEMA public"
pg_restore: [archiver (db)] Error from TOC entry 4429; 0 0 COMMENT SCHEMA public postgres
pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of schema public
Command was: COMMENT ON SCHEMA public IS 'standard public schema';
pg_restore: creating TABLE "public.activity"
pg_restore: creating SEQUENCE "public.activity_id_seq"
...
... creating other objects in the public schema ...
...
WARNING: errors ignored on restore: 3
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'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.