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.
Related
got this error when doing a pg_restore. dump & restore are done using same master account in both source/target. I see its related to pg_repack, but cannot figure out why this error is happening during restore. Please advise
pg_restore: creating DEFAULT ACL "repack.DEFAULT PRIVILEGES FOR SEQUENCES"
pg_restore: [archiver (db)] Error from TOC entry 3204; 826 24360292 DEFAULT ACL DEFAULT PRIVILEGES FOR SEQUENCES rdsadmin
pg_restore: [archiver (db)] could not execute query: ERROR: must be member of role "rdsadmin"
Command was: ALTER DEFAULT PRIVILEGES FOR ROLE rdsadmin IN SCHEMA repack GRANT SELECT,USAGE ON SEQUENCES TO rds_superuser;
pg_restore: creating DEFAULT ACL "repack.DEFAULT PRIVILEGES FOR TABLES"
pg_restore: [archiver (db)] Error from TOC entry 3203; 826 24360291 DEFAULT ACL DEFAULT PRIVILEGES FOR TABLES rdsadmin
pg_restore: [archiver (db)] could not execute query: ERROR: must be member of role "rdsadmin"
Command was: ALTER DEFAULT PRIVILEGES FOR ROLE rdsadmin IN SCHEMA repack GRANT INSERT ON TABLES TO rds_superuser;
Postgres 11.13
Should i drop this extension and recreate in target?
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
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 am trying to export my data from a Google Cloud SQL (PostgreSQL) instance in order to import it into a regular Postgres DB using pg_dump and pg_restore:
pg_dump -h sql_proxy -F t --no-owner --no-acl > backup.tar
pg_restore backup.tar -c
However, when running pg_restore I get these errors:
pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore:
[archiver (db)] Error from TOC entry 197; 1259 17010 TABLE xxx
postgres pg_restore: [archiver (db)] could not execute query: ERROR:
role "postgres" does not exist
Command was: ALTER TABLE public.xxx OWNER TO postgres;
pg_restore: [archiver (db)] Error from TOC entry 198; 1259 17017 TABLE
xxy postgres pg_restore: [archiver (db)] could not execute query:
ERROR: role "postgres" does not exist
Command was: ALTER TABLE public.xxy OWNER TO postgres;
...
I tried a few variations of flags with no luck. I found many articles on how to migrate the other way around (from PostgreSQL to Google Cloud SQL for PostgreSQL) and the Google Cloud docs only describe how to export data to be imported into a Cloud SQL DB again.
I would appreciate any help on how to avoid the errors above and how to migrate the DB with as little changes as possible.
You need to have the roles that are referenced already pre-created in the instance where you want to import the dump.
There are two ways to achieve that:
use pg_dumpall instead of pg_dump or
pg_dumpall --globals-only and then restore that dump (this will create the roles among other things)
I'm having trouble restoring a PostgreSQL backup.
On my own computer I dump a table using the custom backup format.
On the server, I try to restore the file but it gives me several errors:
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 247; 1259 147321 TABLE county postgres
pg_restore: [archiver (db)] could not execute query: ERROR: type "geometry" does not exist
This is what I've done on the server:
pSql -U postgres
/c justice
CREATE EXTENSION postgis;
pg_restore -p 5432 -U postgres -d justice data_import
I'm running PostgreSQL 9.3.2 on both computers. However I've got PostGIS 2.1.1 on my local computer and 2.0.4 on the server. Could that be a problem?
Why is my PostGIS extension not working on the server?
When I do not specify the database it seems to work. However where does the data go? It also writes out all the SQL statements to the screen.
pg_restore -p 5432 -U postgres public_county
PostgreSQL database dump complete
When I try to verify the installation of PostGIS it gives me an error. I think the extension might be improperly installed:
select PostGIS_full_version();
ERROR: function postgis_full_version() does not exist