Is it possible to overwrite database records from dump? - postgresql

I have a dump of PostgreSQL database, which I created with command:
pg_dump database_name > dumpname.sql
I would like to restore database from this dump but I get manny errors "...already exists". Is it possible to overwrite existing database records from dump? I have to restore database, but I can't drop it.

If you use the --clean option of pg_dump, the tables will be dropped and recreated.

Related

PSQL prevent "COMMENT ON" on the DB dump

We are migrating some products, one of the steps is to migrate the product databases.
I have steps to
export the existing DB pg_dump --no-owner --clean --blobs --no-privileges -U dbuser old_dbname -f bkpfile.sql
import the dump to a different DB psql -U dbuser2 new_dbname -f bkpfile.sql
The problem is the old database contains statement COMMENT ON DATABASE old_dbname IS 'Rxxxxx';
The new DB user must not have permissions on the old database and imho it's not good to refer the old database name anyway in the dump.
Is there a way to create a complete DB dump without the COMMENT ON DATABASE statement?
Edit:
PostgreSQL 9.6
Steps to reproduce:
CREATE DATABASE testdb;
COMMENT ON DATABASE testdb IS 'some comment';
CREATE TABLE xx (id int);
and then dump the database, the dump contains reference to the database name COMMENT ON DATABASE testdb IS 'some comment'; which prevents importing the backup to a new database
pg_dump --no-owner --clean --blobs --no-privileges testdb
We could manually remove the comment statement or filter the comment using different tools (grep), but manual intervention or text-based filtering on top of the backup could cause data corruption.
This comment is only dumped in PostgreSQL versions below v11. See this entry in the release notes:
pg_dump and pg_restore, without --create, no longer dump/restore database-level comments and security labels; those are now treated as properties of the database.
9.6 will go out of support soon anyway, so this is a good opportunity to upgrade.

Restoring the data from pg_dump doesn't overwrite the data but it appends the data to the original database

I am taking the dump of postgres database using "pg_dump database_name > backup.sql". Later on I am doing some modifications in the original database(database_name) and then I am restoring the data from the backup file(backup.sql). But the result is that, the database doesn't gets restored to the original state, instead it adds the original data to the modified data(modified + original).I just want it to restore to the original state, shall i delete all the data from the database before restoring it from the backup file, since it gives the original state of the database. Or is there any other way to do this?
The default format fo pg_dump is plain, so it creates a COPY statement. Hence when you psql backup.sql you just run those copy over existing data. To rewrite data, you should either drop tables first or pg_dump -F c and pg_restore -c.
Warning - in both cases it will destroy old data (this seems what you want though)
-c
--clean Clean (drop) database objects before recreating them. (Unless --if-exists is used, this might generate some harmless error messages, if any objects were not present in the destination database.)
As #Craig Ringer suggests, drop/recreate from backup would be much easier and cleaner. To drop database you run DROP DATABASE au - note that there should be no connected users to success. Then you have to create db: CREATE DATABASE au and run psql -f backup.sql -d au
Take the dump with -c option: pg_dump -c database_name > backup.sql. See pg_dump docs.

What causes errors when restoring postgres database?

I'm trying to backup up an entire postgres database and restore it properly, however I am seeing a list of errors when trying to restore the backup.
I am using pg_dump to create a backup sql file. (I have a .pgpass file for password)
sudo -u postgres pg_dump -d db-w > backup.sql
When I try to restore the database with:
sudo -u postgres psql db < backup.sql
I get a list of errors like:
ERROR: duplicate key value violates unique constraint
ERROR: multiple primary keys for table
ERROR: relation <relation> already exists
ERROR: trigger <trigger> for relation <relation> already exist
I haven't made any changes to the database. I simply performed a backup and restore the backup right after.
What am I doing wrong?
your restoring on an existing database, if you want and sure to replace database with the backup you can use option --clean and --create
-c, --clean
Clean (drop) database objects before recreating them. (This might
generate some harmless error messages, if any objects were not
present in the destination database.)
-C, --create
Create the database before restoring into it. If --clean is also
specified, drop and recreate the target database before connecting
to it.

PostgreSQL - copy data from one table, database, server to another table, another database, server

What would be the best way to copy data from one table, one database, one server to the table in another database, another server in PostgreSQL?
pg_dump allows the dumping of only select tables:
pg_dump -Fc -f output.dump -t tablename databasename
(dump 'tablename' from database 'databasename' into file 'output.dump' in pg_dumps binary custom format)
You can restore that dump on your other server with pg_restore:
pg_restore -d databasename output.dump
If the table itself already exists in your target database, you can import only the rows by adding the --data-only flag.
I shared a shell to copy table from one server to another PostgreSQL server.
Please refer this another stack question.
Copying PostgreSQL database to another server

how to restore a single "View" in postgresql

I know how to restore a single table form postgresql database backup file.
For Example: To restore password_history table i use the below command and it works fine.
pg_restore --data-only --table=password_history C:\Users\sjayaram\Desktop\dcmdb-01-17-2014-10-19-18.backup > passwordhistory.txt
Whats the command to restore a single "View" from postgresql database backup file.