Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1U3Tb9-0005lD-C7 for pgsql-admin@arkaria.postgresql.org; Thu, 07 Feb 2013 15:41:15 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1U3Tb8-0003rw-Ev for pgsql-admin@arkaria.postgresql.org; Thu, 07 Feb 2013 15:41:14 +0000 Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1U3Tb7-0003ro-ML for pgsql-admin@postgresql.org; Thu, 07 Feb 2013 15:41:13 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1U3Tb6-0006vP-Gt for pgsql-admin@postgresql.org; Thu, 07 Feb 2013 15:41:13 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id r17FfBel012394; Thu, 7 Feb 2013 10:41:11 -0500 (EST) From: Tom Lane To: Vasiliy I Ozerov cc: pgsql-admin@postgresql.org Subject: Re: Unexpected chunk size when doing dump In-reply-to: References: Comments: In-reply-to Vasiliy I Ozerov message dated "Thu, 07 Feb 2013 17:02:44 +0400" Date: Thu, 07 Feb 2013 10:41:11 -0500 Message-ID: <12393.1360251671@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org Vasiliy I Ozerov writes: > I have an error, when doing database dump: > pg_dump: [archiver (db)] query failed: ERROR: unexpected chunk size 384 (expected 389) in final chunk 1 for toast value 11589 in pg_toast_2619 That looks like a data corruption problem :-(. You might want to check into whether your disks/filesystems are properly configured to honor fsync. Assuming this is the only problem, you're in luck as far as recovery goes, because pg_toast_2619 is the toast table for pg_statistic, which means there's no irreplaceable data in there. I'd suggest truncating pg_statistic (as superuser) and then doing a database-wide ANALYZE to rebuild the content. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin