Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 4EA041337B4E for ; Tue, 26 Oct 2010 09:02:12 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 71124-02 for ; Tue, 26 Oct 2010 12:02:05 +0000 (UTC) X-Greylist: delayed 00:20:16.808912 by SQLgrey-1.7.6 Received: from ns.solnet.cz (ns.solnet.cz [193.165.198.50]) by mail.postgresql.org (Postfix) with ESMTP id A06C01337B4B for ; Tue, 26 Oct 2010 09:02:04 -0300 (ADT) Received: from mail by ns.solnet.cz with scanned-ok (Exim 4.69) id 1PAhuU-0006GD-KS for ; Tue, 26 Oct 2010 13:41:46 +0200 X-AntiVirus: scanned for viruses by soLNet AVirCheck 2.0.60 (http://www.solnet.cz/avircheck) Received: from localhost ([127.0.0.1] helo=solnet.cz) by ns.solnet.cz with esmtpa (Exim 4.69) id 1PAhuU-0006Fa-DI for ; Tue, 26 Oct 2010 13:41:46 +0200 Date: Tue, 26 Oct 2010 13:41:44 +0200 From: =?utf-8?Q?Martin_Povolny?= To: pgsql-admin@postgresql.org Subject: =?utf-8?Q?large_database=3A_problems_with_pg=5Fdump_and_pg=5Frestore?= Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=mimepart_4cc6be7a60314_19e4..fdbeb90dc5e6 User-Agent: InChange X-Priority: 0 Message-Id: X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.909 tagged_above=-10 required=5 tests=BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201010/185 X-Sequence-Number: 35926 --mimepart_4cc6be7a60314_19e4..fdbeb90dc5e6 Content-Type: text/plain; charset=utf-8 Hallo, I have some quite grave problems with dumping and restoring large databases (>4GB of dump). I had 5 databases, 4 dumped ok, the 5th, the largest failed dumping: I was unable to make a dump in the default 'tar' format. I got this message: pg_dump: [tar archiver] archive member too large for tar format I got over this issue by using the 'custom' format. Unfortunately later on I was only able to restore 3 of the 5 databases -- any of the 2 dumps that would get over 4GB in the 'tar' format would fail. /var/tmp# ls -l dumps/ total 16294020 -rw-r--r-- 1 root root 742611968 2010-10-16 20:36 archiv1.dump -rw-r--r-- 1 root root 317352448 2010-10-16 20:37 archiv2.dump -rw-r--r-- 1 root root 1137477632 2010-10-16 20:41 archiv3.dump -rw-r--r-- 1 root root 3712833536 2010-10-16 20:57 archiv4.dump -rw-r--r-- 1 root root 8735429632 2010-10-16 21:35 archiv5.dump -rw-r--r-- 1 root root 1253325453 2010-10-16 22:59 bb.dump archiv1-4 went OK, archiv5 -- the largest in 'tar' format -- failed and the 'bb.dump' which is in the 'custom' format, failed too. I got these messages: for the archiv5 in the 'tar' format: pg_restore: [tar archivář] nalezena poškozená tar hlavička v STEX (předpokládáno 100, vypočteno 34044) pozice souboru 7750193152 sorry, it's in my native locale, but is says "found a corrupted tar header in STEX (expected 100, calculated 34044) file position 7750193152 for the bb.dump in the 'custom' format: pg_restore: [vlastní archivář] unexpected end of file 'vlastní archivář' is again in my locale, it should be in English "own archiver" Later I tried to utilize the -I and -i switches of pg_restore to restore data that are in the archive behing the table that was not restored. But got the same error message. The dump was created on postgresql-8.3 8.3.3-1~bpo40+1 from debian backports. I was trying to restore on this version and later on using postgresql-8.4 8.4.5-1~bpo50+1 from debian backports, finally I tried 64bit version of postgresql-8.4 8.4.5-0ubuntu10.10. No change, still the same error messages. I welcome any help and/or hints on this issue as I need to dump and restore several large databases. Regards, -- Mgr. Martin Povolný, soLNet, s.r.o., +420777714458, martin.povolny@solnet.cz --mimepart_4cc6be7a60314_19e4..fdbeb90dc5e6 Content-Type: text/html; charset=utf-8 Hallo, 

I have some quite grave problems with dumping and restoring large databases (>4GB of dump).

I had 5 databases, 4 dumped ok, the 5th, the largest failed dumping: I was unable to make a dump in the default 'tar' format. I got this message:

pg_dump: [tar archiver] archive member too large for tar format

I got over this issue by using the 'custom' format.

Unfortunately later on I was only able to restore 3 of the 5 databases -- any of the 2 dumps that would get over 4GB in the 'tar' format would fail.

/var/tmp# ls -l dumps/
total 16294020
-rw-r--r-- 1 root root  742611968 2010-10-16 20:36 archiv1.dump
-rw-r--r-- 1 root root  317352448 2010-10-16 20:37 archiv2.dump
-rw-r--r-- 1 root root 1137477632 2010-10-16 20:41 archiv3.dump
-rw-r--r-- 1 root root 3712833536 2010- 10-16 20:57 archiv4.dump
-rw-r--r-- 1 root root 8735429632 2010-10-16 21:35 archiv5.dump
-rw-r--r-- 1 root root 1253325453 2010-10-16 22:59 bb.dump

archiv1-4 went OK, archiv5 -- the largest in 'tar' format -- failed and the 'bb.dump' which is in the 'custom' format, failed too.

I got these messages:

for the archiv5 in the 'tar' format: 

pg_restore: [tar archivář] nalezena poškozená tar hlavička v STEX (předpokládáno 100, vypočteno 34044) pozice souboru 7750193152

sorry, it's in my native locale, but is says "found a corrupted tar header in STEX (expected 100, calculated 34044) file position 7750193152

for the bb.dump in the 'custom' format:

pg_restore: [vlastní archivář] unexpected end of file

'vlastní archiv ář' is again in my locale, it should be in English "own archiver"

Later I tried to utilize the -I and -i switches of pg_restore to restore data that are in the archive behing the table that was not restored. But got the same error message.

The dump was created on postgresql-8.3  8.3.3-1~bpo40+1 from debian backports. I was trying to restore on this version and later on using postgresql-8.4 8.4.5-1~bpo50+1 from debian backports, finally I tried 64bit version of postgresql-8.4 8.4.5-0ubuntu10.10. No change, still the same error messages.

I welcome any help and/or hints on this issue as I need to dump and restore several large databases.

Regards,

--
Mgr. Martin Povolný, soLNet, s.r.o.,
+420777714458, martin.povolny@solnet.cz
--mimepart_4cc6be7a60314_19e4..fdbeb90dc5e6--