I am new with postgresql.

When I attempt to restore database a .sql.gz file into the database with psql, the restore does not complete when the database size is too large (32Gb, for example).

These reason again I restore empty tables. How can I resolve this issue?

psql -U postgres -d dbname -f <filename>
  • 1
    How is the backup created? And what's the exact error message you're getting? The tar backup type has a 8GB limit, other than that it shouldn't be any size limits. – Trygve Laugstøl Jan 16 '13 at 21:25
  • No actually, when i restore database file into database then its hold too long and not restore complete data restore or even my last some tables were empty. By the way my some small database like 1 gb or 3 gb is restore easily, but not of 6 gb in zip format file. plz help me – Leo Jan 17 '13 at 8:27
  • I do dump from producation server database use pg_dump cmd and its restore into dev. server database through psql cmd. database size around 6.5 gb in zip format. It hold restore even full one day and not store complete data. – Leo Jan 17 '13 at 8:30
  • Can you include the exact pg_dump command you're using? pg_dump does not support zip so I wonder what kind of back you really have. Do you mean "gzip" when you say "zip"? They're two different things. – Trygve Laugstøl Jan 17 '13 at 10:36
  • No when i use pg_dump cmd (database size 33 gb without zip )its work well, but when i use psql for same to restoration in to other server database. its take long time (more than 1.5 days) even not complete restoration of database tables. why this issue arries, and how complete this task. plz help command I use : #pg_dump dbname > filename &&&& # psql -U postgres -d dbname < filename . – Leo Jan 18 '13 at 9:04

It may not be the data size, but rather the number of tables and schemas. Database dumps and restores are known to run into problems in those cases.

For large backups the preferred backup approach is to use pg_basebackup which creates a snapshot of the database files at a specific time. These are restored much faster. Unfortunately this does not necessarily work for certain sorts of things, like restoring across major versions (but see pg_upgrade).

the raw data size is not a problem. But in your case, pg_dump may not be very useful and you may want to look at other ways of making a backup.

| improve this answer | |

This comment may help you if you can change parameters of pg_dump:

The comments at your post indicates that you have issues with backup and restore big databases.

For huge databases i recommend you using the custom format of pg_dump -Fc that are handled also for really huge databases by postgres well. (no issues with this up to 300GB)

Usage example:

pg_dump -Fc -U <user> -f <filename.dmp> <database>

to restore:

pg_restore -Fc -j <jobs> -U <user> <filename.dmp>

The custom format allows you to import your dump into the dev system with more than one thread. That means at the index creation on the dev server you can with 4 jobs use up to 4 cores for INDEX creation or ALTER TABLE statements in parallel.

If you need more options, have a look at the documentation of pg_dump and pg_restore.

I hope my knowledge about DnR in this post can help you save a lot of time trying to import dumps.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.