Re: PG dump and restore - Mailing list pgsql-general

From Thom Brown
Subject Re: PG dump and restore
Date
Msg-id AANLkTimCc11B8mW3d5iWwMCD4yV5Q7ly3x4AGEssVDmN@mail.gmail.com
Whole thread Raw
In response to Re: PG dump and restore  (Dennis C <dcswest@gmail.com>)
List pgsql-general
On 26 June 2010 00:59, Dennis C <dcswest@gmail.com> wrote:
> OK well the gunzip seemed to "do the trick," but I don't recall before
> having to do anything other than run the pg_restore command.  Anyway, thanks
> to everyone for all your help!
>
>
> On Fri, Jun 25, 2010 at 11:29 AM, Adrian Klaver <adrian.klaver@gmail.com>
> wrote:
>>
>> On 06/25/2010 09:04 AM, Dennis C wrote:
>>>
>>> It says "Trading-Access: gzip compressed data, from Unix"
>>>
>>> About the idea of not using pg_restore for these dumps, what I'm still
>>> missing is how it's worked for all these years before.  Are there now
>>> more
>>> stringent standards being enforced?
>>>
>>>
>>
>> You have restored from these dumps using pg_restore?
>>
>> The command below says create a plain text file that has commands to clean
>> database objects before recreating and store text in file ./Trading-Access
>> using gzip compression at level 5:
>>
>> /opt/local/lib/postgresql84/bin/pg_dump -c -f ./Trading-Access -Z 5
>> Trading-Access
>>
>> To restore I would think you need to gunzip ./Trading-Access and then feed
>> the file to psql.
>>
>>

It appears that if you don't specify the file format, but you specify
compression, it uses plain format but then gzips it up.

Thom

pgsql-general by date:

Previous
From: Felipe de Jesús Molina Bravo
Date:
Subject: Re: pl-perl for 64 bits in Solaris 9
Next
From: wei725@lycos.com
Date:
Subject: Any problem with the Long Integer type?