When trying to make a postgreSQL database dump we got the following error and the process stops immediately.
Command used:
openbravo#master.akluck.com:~
07/26 11:48:11> pg_dump -U tad -h localhost -p 5932 -F c -b -v -f /home/openbravo/dump26072018.dmp openbravo
Output:
pg_dump: reading schemas
pg_dump: reading user-defined tables
pg_dump: schema with OID 67046 does not exist
pg_dump: *** aborted because of error
Can anyone guide me how to sort this issue?
Update:
I followed this tutorial
http://www.aukema.org/2011/06/fixing-complex-corruption-in-my-dna.html
And I can see there are objects without a schemaname in the pg_tables.
But I don't know how to update those missing schemanames in the pg_tables. The last part of the tutorial is not quite explanatory. Hope someone can throw some light.
Finally found a way to take the backup by excluding the corrupted table as follows
pg_dump --exclude-table=ad_context_info -h localhost -p 5932 -U postgres > dumpsabnew.dmp
Related
I'm having trouble performing the restore from a dump. The scenario is as follows: I am migrating an environment from GCP to AWS, and at the moment I am working on the migration of the bank.
A partner dumped db that is in GCP and placed the file on AWS S3 (I don't know the command he used to perform the dump).
I created an EC2 in the AWS environment and copied the dump from S3 to EC2 (the file is 13 GB). I also created the RDS to host the new db with all the correct security group settings.
Here comes the problem, I connect to the RDS from the server (EC2) without problems, but when doing the restore using pg_restore I get the following error message: pg_restore: too many command line arguments (first is "dbclient. dump ").
The complete command I used was this:
pg_restore -h client-aurora-cluster-hmg-legado-instance-1.c23ltjbbz7ms.us-east-1.rds.amazonaws.com -U postgres -d db_hmg_legado dbclient.dump -W
OK, I changed the approach. I tried with psql instead of pg_restore and then the command was like this:
psql -h client-aurora-cluster-hmg-legado-instance-1.c23ltjbbz7ms.us-east-1.rds.amazonaws.com -U postgres -d db_hmg_legado dbclient.dump -W
Only this time it worked !!!!
But I received some error messages while performing the restore. Which I put below:
psql: dbclient.dump: 23: ERROR: schema "dw" already exists
CREATE EXTENSION
psql: dbclient.dump: 37: ERROR: must be owner of extension hstore
CREATE EXTENSION
psql: dbclient.dump: 51: ERROR: must be owner of extension intarray
CREATE EXTENSION
psql: dbclient.dump: 65: ERROR: must be owner of extension pg_trgm
CREATE EXTENSION
psql: dbclient.dump: 79: ERROR: must be owner of extension unaccent
But the restore takes a long time and is partially finished.
In general I wanted to understand why pg_restore didn't work. Has anyone ever experienced this?
And about these owner errors does anyone know how to resolve this using psql?
As documented in the manual the file to be restored is the last parameter and it is specified without a "switch". But you are using -W after the dump file. Move the -W parameter somewhere before that (although it's usually not necessary to begin with)
So you need something like this:
pg_restore -W -h ... -U postgres -d db_hmg_legado dbclient.dump
However, if the restore worked when using psql then the dump file is a "plain text" dump which can't be restored using pg_restore to begin with.
Concerning the errors:
You should restore the dump into an empty database that doesn't contain any schemas except the default ones.
You need a superuser for CREATE EXTENSION, which you don't have in a hosted database. So pre-install these extensions with the techniques that Amazon provides, then restore the dump and ignore the errors.
I Tried to take a dump of my database. While Dumping i received the below error. I knew a table in my database is corrupted and i can use exclude option to exclude the corrupted table and take dump of the remaining tables. But I am searching for an option to dump even the corrupted table excluding the invalid page blocks.
The command i used to take dump is :
pg_dump -U postgres -p 5432 -d DBNAME -v -n SCHEMA_NAME -f "OUTFILE.sql"
The error prints:
pg_dump: Dumping the contents of table "TABLE_NAME" failed: PQgetResult() failed.
pg_dump: Error message from server: ERROR: invalid page in block 2145280 of relation base/16384/25464
I was able to access the corrupted table and its data. So i believe the part of the data which i can access can be dumped. Kindly share if there is any possibility to achieve this.
You could set zero_damaged_pages = on, then PostgreSQL should zero (and ignore) such pages.
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 would like to copy two tables from database A to database B, in postgres
how can I do it using pg_dump without losing the previous tables and data in database B ?
I read some answers in Stack Overflow suggesting using pg_dump but in the documentation page I read?
The idea behind this dump method is to generate a text file with SQL
commands that, when fed back to the server, will recreate the database
in the same state as it was at the time of the dump
Doesn't that mean it will delete the previous data in database B?
If someone could tell me step by step solution to move two tables in database A to database B without losing any previous data in Database B, it would be helpful.
I found the answer to my question :
sudo -u OWNER_USER pg_dump -t users databasename1 | sudo -u OWNER_USER psql databasename2
if you pg_restore a database into b database, of course a will replace b. instead pick specific table you would like to restore using pg_restore -t
you could pg_restore to different schema, by using -O (no_owner)
so let say
pg_dump -Fc -f dump.dmp -v -h host -U user_login -n schema_to_dump
you can
pg_restore -v -h host -U user_login -n schema_to_import -a --disable-triggers dump.dmp
I moved my PostgresQL database from one hard drive to another using
pg_dump -U postgres db_name > db_name.dump
and then
psql -U postgres db_name < db_name.dump
I created the database db_name the same way in both instances. In the new database when I run my Java program with a JPA query (or a JDBC query) I get this error:
"ERROR: relation "table1" does not exist"
The query is:
select count(0) from table1
I know I've got a connection because if I change the password in the connection parameters I get an error.
For some reason in the new PostgresQL instance it thinks that table1 does not exist in the imported schema.
If I change the query to
select count(0) from myschema.table1
Then it complains about permissions:
"ERROR: permission denied for schema myschema"
Why would the permissions be different?
The table table1 exists in myschema because I can see it in the pgAdmin tool. All the rows were imported into the new PostgresQL instance.
When I do a query from Java the combination of pg_dump and psql created a problem.
What do I need to do to solve this issue?
Are you moving to the same version of PostgreSQL? There might be issues if you make a dump with pg_dump 8.3 and try to restore it in Postgresql 8.4. Anyway, assuming that it is the same version try the following:
Dump all global objects, such as users and groups (don't know if they were missing in your dump):
pg_dumpall -g -U postgres > globals.sql
Dump schema of database:
pg_dump -Fp -s -v -f db-schema.sql -U postgres dbname
Dump contents of database:
pg_dump -Fc -v -f full.dump -U postgres dbname
Now restore.
psql -f globals.sql
psql -f db-schema.sql dbname
pg_restore -a -d dbname -Fc full.dump
That is my $0.02. Hope it helps.
I encountered this problem. Then I realized that I forgot to install postgis extension.
Don't forget to install the extensions you use.
I was able to solve it by changing the database privileges to public CONNECT and the schema privileges for public and postgres = USAGE and CREATE.
My backup scripts apparently didn't preserve the privileges, at least not when moving from 8.3 to 8.4.