I dumped the database with:
pg_dump dsmartgpp -f /data1/master/backup/db.sql
and I copied the database with
nohup psql -h gpnm1 -d dsmartgpp_1 -U gpadmin < /data1/master/backup/db.sql
the log information showed some errors about the function and datatype of postgis, such as
ALTER FUNCTION
ERROR: function "gidx_out" already exists with same argument types.
ALTER FUNCTION
ERROR: type "gidx" already exists
some tables between the two database have the same number or records, but about 1MB difference in size.
That is as expected. Restoring a pg_dump creates a logical copy of the database. In particular, the copy won't be bloated (don't worry – a bit of bloat is healthy).
If you want to avoid these errors, create the new database (dsmartgpp_1) with template0 as template (empty database). You seem to have PostGIS installed in template1, which gets copied into every new database. Or you installed PostGIS in your new database, before importing the dump.
Either way, create the empty database (dsmartgpp_1) and let the dump install the PostGIS functions.
Oh, one more thing, you can use "-f /data1/master/backup/db.sql" instead of the "<" redirect.
If you want to be super careful, also add "-v ON_ERROR_STOP=1". This will stop at the first error.
Related
I have 2 Postgres tables (same schema) in different servers.
One table has the the latest data, and the other one has old data that must be updated with the latest data.
So I dump the table with the latest data:
pg_dump --table=table00 --data-only db00 > table00.sql
or
pg_dump --table=table00 --data-only --column-inserts db00 > table00.sql
But now when I want to read in the SQL dump, I get errors about duplicate keys.
psql postgresql://<username>:<password>#localhost:5432/db00 --file=table00.sql
The error goes away if I drop the table with the old data first, but not only is this undesirable, it is plain silly.
How can I update a Postgres table from a SQL dump then?
Eg. it'd be nice if pg_dump had a --column-updates option, where, instead of INSERT statements, you got INSERT ON CONFLICT (column) DO UPDATE SET statements...
I would like to copy data from table A database A to table b database b in postgres.
I am able to use copy to write data out to a file from table A in DB A
but when I try copy into database b table B it says "ERROR: must be super user to copy to and from file"
Please help and let me know how I should data from a flatfile into a table in a database.... the db is postgres 9.x
According to the documentation:
COPY naming a file or command is only allowed to database superusers or users who are granted one of the default roles pg_read_server_files, pg_write_server_files, or pg_execute_server_program, since it allows reading or writing any file or running a program that the server has privileges to access.
However you can use pipeline to transmit data from one database to another one without using of intermediate file(s):
psql -d A -c "copy a to stdout" | psql -d B -c "copy b from stdin"
Read more about psql utility and its usage.
I have two postgres databases on the same server, a live one and another one which I use as a test database.
Periodically I need to copy my live database (both structure of the tables and their data) into the test one, but everything I've found online only copies table by table. Since I often create new tables in my live db I can't do this, otherwise I'd have to update the job every time.
Anybody knows how can I pull the whole live postgres db into the test postgres one?
Thanks!
You want to use pg_dump and pg_restore.
Example usage would be:
$ pg_dump -Fc <database_name> > dumpfile
$ pg_restore <another_database_name> < dumpfile
If you want to do this for all database you might want to consider pg_dumpall
A bit more can be found in https://www.postgresql.org/docs/current/backup-dump.html
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.
Context: I'm new on a big project, with a huge number of PostgreSQL tables (46) and foreign keys, and no documentation. We work with Java, Spring, Hibernate and TestNG.
Goal: I'm looking for a script that's able to empty the database (to call it before every unit-test case). Unfortunately, I can't spend too much time to find foreign keys in order to empty tables in the correct order.
Question: is there a way to empty (I don't want to drop it) a table without checking constraints on foreign keys ?
As #a_horse_with_no_name commented, using truncate ... cascade for each table will work. The link also provides a function that automatically loops through all the tables in the database.
If you have large tables, with a lot of foreign keys, it will probably take a lot of time to travel through all the foreign key indexes. In that case it would probably be better to dump the schema, drop the database, recreate the database and reload the schema in a batch. There is an example in the link, but it doesn't tell you how to run them. This is a little more refined:
#!/bin/sh
# Run this as the postgres user because you need create database permissions
# I'm assuming you're using a Unix variant,
# the postgresql database is at localhost,
# and that psql trusts the Unix account.
# Otherwise add -h hostname to the command lines
# and set $PGPASSWORD variable before the first command.
pg_dump –s yourdb > /tmp/clean.sql
psql –c "drop database yourdb;"
psql –c "create database yourdb with owner you;"
psql yourdb < /tmp/clean.sql
rm –f /tmp/clean.sql