A number of errors are being generated when calling pg_restore -c -d app_development -Fc [...]
Some are straightforward, but others leave space for doubts (in this reader's mind)
Most seem to be derived from the fact that on one server, the user is welcome and on the second server the usr is deploy
pg_restore: error: could not execute query: ERROR: must be owner of extension plpgsql
Command was: DROP EXTENSION plpgsql;
pg_restore: error: could not execute query: ERROR: must be owner of schema public
[...]
pg_restore: WARNING: no privileges could be revoked for "public"
pg_restore: WARNING: no privileges could be revoked for "public"
pg_restore: WARNING: no privileges were granted for "public"
pg_restore: WARNING: no privileges were granted for "public"
The documentation refers to two commands -O and --no-owner command.
The documentation states With -O, any user name can be used for the initial connection, and this user will own all the created objects. which appears to resolve this ownership substitution in the restore process, but I remain uncertain, as no example is provided. (and which of the two is to use, where?)
pg_restore -c -d -O
leads to error pg_restore: error: too many command-line arguments
Related
The PostgreSQL version I am trying to restore is 9.4.10. I backed up a database from the same version. The command I am using for restore is:
/opt/PostgreSQL/9.4/bin/pg_restore -U postgres --port=5432 -v --dbname=mydb < /backups/309646/WAL/pipe_309646
The error I get is:
pg_restore: executing BLOB 71197
pg_restore: [archiver (db)] Error from TOC entry 3822; 2613 71197 BLOB 71197 user
pg_restore: [archiver (db)] could not execute query: ERROR: duplicate key value violates unique constraint "pg_largeobject_metadata_oid_index"
DETAIL: Key (oid)=(71197) already exists.
Command was: SELECT pg_catalog.lo_create('71197');
This is repeated in the pg errors some 112 times. I need to restore to the same database. Here is the command I used for dumping:
/opt/PostgreSQL/9.4/bin/pg_dump" -U postgres -Fc -b --port=5432 'mydb' -t public.users > /backups/309646/WAL/pipe_309646
Any indication as to why this is happening? How can I mitigate this error?
You are trying to restore a large object into a database that already contains a large object with the same oid.
Use a new database that does not contain any large objects yet as target for the restore.
Alternatively, drop the large objects first with
SELECT lo_unlink(oid) FROM pg_largeobject_metadata;
I've been handed a project from a coworker with zero knowledge of Postgres. I'm trying to integrate a pg_restore into a Jenkins Pipeline job and it returns one error that I have been told is fine to overlook. However, this error obviously causes the Jenkins job to fail, which is unideal.
Is there a way to mitigate or stifle the output of this one error, without stopping any other (more serious) errors from being recorded?
The command I am running (with all personal data stripped) is
PGPASSWORD="password" pg_restore -h path -U user -d database filename -F c -c
and it returns this error (but executes successfully)
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 8290; 0 0 COMMENT EXTENSION plpgsql
pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of extension plpgsql
Command was: COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language';
Again, I have less than zero Postgres experience. Is there an easy way to ignore this one error, or is this just something I need to live with?
If you run pg_restore as the user who owns the extension in the source database, that would fix the problem for real.
For just suppressing the issue: with old-style script steps, adding #!/bin/sh -x as the first line would prevent it from aborting on a non-zero return code (Jenkins normally runs shells with the -e option as well). It's worth a shot with a pipeline build but I don't know for sure if it'll work the same way. If it does, do be aware that the script will continue after other bad return codes as well.
I'm trying to restore a Postgres database, with the following command:
pg_restore --verbose -h localhost -p 5436 -d my_database --format=c --clean --no-owner --no-privileges --no-tablespaces --jobs=1 Sunday2.backup
During the restore, I see this error:
pg_restore: [archiver (db)] Error from TOC entry 2540; 0 16531 TABLE DATA foo_searchresult uoj9bg6vn4cqm
pg_restore: [archiver (db)] COPY failed for table "foo_searchresult": ERROR: duplicate key value violates unique constraint "foo_searchresult_pkey"
DETAIL: Key (id)=(63) already exists.
CONTEXT: COPY foo_searchresult, line 1
I went back to the source database and ran this:
select id, count(*)
from foo_searchresult
group by id
having count(*) > 1
and got nothing.
Now if I just try to restore that one table to a brand-new database:
pg_restore --verbose -h localhost -p 5436 -d brand_new_database --format=c --clean --no-owner --no-privileges --no-tablespaces --jobs=1 -t foo_searchresult Sunday2.backup
it comes back clean.
UPDATE: I just tried restoring the ENTIRE backup to a brand-new database, and it seems to have made it past foo_searchresult without issue.
(Incidentally, the source database is 9.4, and the target database is 9.5, but I get the same results using the pg_restore from a 9.4 or 9.5 distribution.)
UPDATE: So it seems that dropping the database, then creating an empty one and re-loading that (rather than using the --clean flag) resolved a whole multitude of issues
Anyway, my question was "Has anyone seen this before, or have any idea how to fix it."
I need to be able to somehow get a set of tables from my dev db into my production db. I've just been creating a dump file from the dev db and using pg_restore on the production db. The problem now is that I need to preserve one table(called users) on the production db while replacing the others
I think I have the dump properly from this command
pg_dump -Fc --no-acl --no-owner -h localhost -U <USER> --exclude-table=users* --data-only <DB NAME> > test.dump
But I can't get the restore part to work. I tried the following command
pg_restore -Fc --no-acl --no-owner -h <PROD HOST> -U <USER> -d <DB NAME> -p <PORT> <FILE LOCATION>
BUt I get the following errors
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 2009; 0 121384 TABLE DATA idx_descs Jason
pg_restore: [archiver (db)] COPY failed for table "idx_descs": ERROR: duplicate key value violates unique constraint "idx_descs_pkey"
DETAIL: Key (id)=(6) already exists.
CONTEXT: COPY idx_descs, line 1
It seems like for the tables I'm trying to overwrite, it is just trying to append the data and running into trouble because there are now duplicate primary keys. Any Ideas how to do this? Thanks
So you need to reassign primary keys?
You could try restoring to a temporary table (say for instance, in failing case: idx_desc_temp), then doing something like:
with t as ( select * from idx_descs_temp )
insert into idx_descs
select id + 100000 [or whatever], [other fields] from t;
Afterwards you need to reset sequences (if applicable -- fill in sequence name....):
select setval( 'idx_descs_id_seq'::regclass, 100000 + [suitable increment]);
If you have a large # of tables you could try to automate using the system catalog.
Note though that you also have to renumber foreign key refs. Possibly less pain would be to move data in production db first. If you are using an ORM, you could also automate via application APIs.
I'm attempting to import a PostgreSQL dump from heroku into a local database (to mimic production data in a local environment). I'm working with postgres 9.2 locally on OSX. Here are the steps I've taken in my console:
dropdb db_dev
createdb db_dev
heroku pgbackups:capture HEROKU_POSTGRESQL_MAROON_URL
curl -o latest.dump `heroku pgbackups:url`
pg_restore --verbose --clean --no-acl --no-owner -h localhost -U connorwarnock -d db-dev latest.dump
And the subsequent errors:
pg_restore: connecting to database for restore
pg_restore: dropping COMMENT EXTENSION plpgsql
pg_restore: dropping EXTENSION plpgsql
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 6; 2615 2200 SCHEMA public whgnwlkesexkyo
pg_restore: [archiver (db)] could not execute query: ERROR: cannot drop schema public because other objects depend on it
DETAIL: extension hstore depends on schema public
HINT: Use DROP ... CASCADE to drop the dependent objects too.
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: creating EXTENSION plpgsql
pg_restore: creating COMMENT EXTENSION plpgsql
pg_restore: setting owner and privileges for SCHEMA public
pg_restore: setting owner and privileges for COMMENT SCHEMA public
pg_restore: setting owner and privileges for EXTENSION plpgsql
pg_restore: setting owner and privileges for COMMENT EXTENSION plpgsql
WARNING: errors ignored on restore: 2
No data is imported. It seems that the public schema is causing issues (I've dropped the schema manually and tried again, to no avail). Perhaps the hstore extension is causing trouble? Any other ideas on how to avoid these errors?
It looks like your template1 contains the hstore extension and possibly other changes.
I'd suggest dropping db_dev and re-creating it from template0, the read-only template that contains the basic default database.
createdb -T template0 dev_db
If that doesn't do the trick, please post updated errors and comment here.