Re: Strange result using pg_dump gzip or split. - Mailing list pgsql-general

From Francisco Olarte
Subject Re: Strange result using pg_dump gzip or split.
Date
Msg-id CA+bJJbwgfy7fUjXjwmc_pDq6Qqaojh=3NhdFdLZbJkQ495VbYw@mail.gmail.com
Whole thread Raw
In response to Strange result using pg_dump gzip or split.  (Condor <condor@stz-bg.com>)
List pgsql-general
Hi Condor.

On Mon, Nov 10, 2014 at 12:34 PM, Condor <condor@stz-bg.com> wrote:
I have a database with 30 gb data and decide to archive it, postgresql is 9.3.5 x64_86, ext4 file system, kernel 3.14.18 Slackware 14.2 (current)

You should have a look at your tools, it seems you have a file size problem....
 
First I use gzip with : pg_dump logdb | gzip > log.sql.gz
...
 $ gzip -l log.sql.gz
         compressed        uncompressed  ratio uncompressed_name
         2170016226          3060688725  29.1% log_to.sql
$ unzip -v log.sql.zip
*** snip ***
--------          -------  ---                            -------
20240557909         2170020867  89%                            20 files

When you have this kind of problem, your first thing should be to pass everything to hex:

2170016226=0x8157D1E2

2170020867=0x8157E403


Not a great difference there, this is normal, but on the uncompressed side:


20240557909=0x4B66E6755

3060688725=0xB66E6755

Mmmm, something phisy here, it seems gzip is using 32 bits only, so it gets the things wrong.  You can investigate more from there. If you can spare the disk space ( which seems to since you had it for the split/zip ) you should try to gunzip it, and see how big it comes out ( I would recommenf 'gzip -tv once to see what it does print, and then gunzip -cv > xxx to preserve the input AND get verbose output ). The problem seems to be with gzip.

Francisco Olarte.



pgsql-general by date:

Previous
From: Francisco Olarte
Date:
Subject: Re: justify_interval: days in year
Next
From: Francisco Olarte
Date:
Subject: Re: Strange result using pg_dump gzip or split.