Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id A1520633082 for ; Thu, 12 Feb 2009 18:13:25 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 00285-02 for ; Thu, 12 Feb 2009 18:13:21 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 07366633083 for ; Thu, 12 Feb 2009 18:13:21 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id n1CMD3qW017765; Thu, 12 Feb 2009 17:13:03 -0500 (EST) To: John Lister cc: pgsql-hackers@postgreSQL.org Subject: Re: [ADMIN] database corruption help In-reply-to: <4994987F.1030204@kickstone.com> References: <507152DDF8AB4DF093BD01A8BEC7C659@squarepi.com> <17205.1234200693@sss.pgh.pa.us> <4990840C.4090900@kickstone.com> <20151.1234208044@sss.pgh.pa.us> <49908D72.7040904@kickstone.com> <25753.1234224090@sss.pgh.pa.us> <4991338B.704@kickstone.com> <4994906B.6090408@kickstone.com> <17204.1234474784@sss.pgh.pa.us> <4994987F.1030204@kickstone.com> Comments: In-reply-to John Lister message dated "Thu, 12 Feb 2009 21:45:35 +0000" Date: Thu, 12 Feb 2009 17:13:03 -0500 Message-ID: <17764.1234476783@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200902/714 X-Sequence-Number: 134004 John Lister writes: > GMT LOG: relation "pg_class" TID 15538/4: dead HOT-updated tuple --- > cannot shrink relation Hmm. The comments in vacuum.c about this case suppose that it could only be a transient condition, ie the tuple became dead while we were looking at the page. Evidently it's persistent for you, which means that for some reason heap_page_prune() is failing to remove an already-dead tuple. I suspect this implies a corrupt HOT chain, but maybe the data is okay and what you've got is really a bug in heap_page_prune. Could you send a dump of page 15538 of pg_class, using pg_filedump? The source code for it is here: http://sources.redhat.com/rhdb/utilities.html Best would be -i -f format, ie pg_filedump -i -f -R 15538 $PGDATA/base/something/1259 regards, tom lane