Use pg_restore to restore from a newer version of PostgreSQL

前端 未结 5 2177
难免孤独
难免孤独 2020-12-16 00:32

I have a (production) DB server running PostgreSQL v9.0 and a development machine running PostgreSQL v8.4. I would like to take a dump of the production DB and use it on the

相关标签:
5条回答
  • 2020-12-16 00:44

    I had same issue. I used pgdump and psql for export/import DB.

    1.Set PGPASSWORD

    export PGPASSWORD='h0ld1tn0w';
    

    2.Export DB with pg_dump

    pg_dump -h <<host>> -U <<username>> <<dbname>> > /opt/db.out 
    

    /opt/db.out is dump path. You can specify of your own.

    3.Then set again PGPASSWORD of you another host. If host is same or password is same then this is not required.

    4.Import db at your another host

    psql -h <<host>> -U <<username>> -d <<dbname>> -f /opt/db.out
    

    If username is different then find and replace with your local username in db.out file. And make sure on username is replaced and not data.

    0 讨论(0)
  • 2020-12-16 00:58

    I solved this by upgrading postgresql from 8.X to 9.2.4. If you're using brew on Mac OS-X, use -

    brew upgrade postgresql
    

    Once this is done, just make sure your new postgres installation is at the top of your path. It'll look something like (depending on the version installation path) -

    export PATH=/usr/local/Cellar/postgresql/9.2.4/bin:$PATH
    
    0 讨论(0)
  • 2020-12-16 01:02

    Using pg_dump/pg_restore to move from 9.0 to 8.4 is not supported - only moving forward is supported.

    However, you can usually get the data across (in a data-only dump), and in some cases you can get the schema - but that's mostly luck, it depends on which features you're using.

    You should normally use the target version of pg_dump and pg_restore - meaning in this case you should use the binaries from 8.4. But you should use the same version of pg_dump and pg_restore. Both tools will work fine across the network, so there should be no need to copy the binaries around.

    And as a_horse_with_no_name says, you may be better off using pg_dump in plaintext mode - that will allow you to hand-edit the dump if necessary. In particular, you can make one schema only dump (with -s) and one data only dump - only the schema dump is likely to require any editing.

    0 讨论(0)
  • 2020-12-16 01:04

    pg_restore is only for restoring dumps taken in the "custom" format.

    If you do a "plain text" dump you have to use psql to run the generated SQL script:

    psql -f nvdls.db dbname username 
    
    0 讨论(0)
  • 2020-12-16 01:07

    If the 9.0 database contains any bytea columns, then bigger problems await.

    These columns will be exported by pg_dump using the "hex" representation and appear in your dump file like:

    SELECT pg_catalog.lowrite(0, '\x0a2')

    Any version of the postgres backend below 9.0 can't grok the hex representation of bytea, and I can't find an option to tell pg_dump on the 9.0 side to not use it. Setting the default "bytea_output" setting to ESCAPE for either the database or the whole server is seemingly ignored by pg_dump.

    I suppose it would be possible to post-process the dump file and actually change every hex-encoded bytea value to an escaped one, but the risk of untraceably corrupting the kind of things normally stored in a bytea (images, PDFs etc) does not excite me.

    0 讨论(0)
提交回复
热议问题