Received: from maia.hub.org (maia-5.hub.org [200.46.204.29])
	by mail.postgresql.org (Postfix) with ESMTP id 53BEA1337B4E
	for <pgsql-admin-postgresql.org@mail.postgresql.org>;
	Fri, 25 Mar 2011 05:50:17 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024)
	with ESMTP id 55263-01 for
	<pgsql-admin-postgresql.org@mail.postgresql.org>;
	Fri, 25 Mar 2011 08:50:07 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from fmmailgate02.web.de (fmmailgate02.web.de [217.72.192.227])
	by mail.postgresql.org (Postfix) with ESMTP id 7A5C91337B43
	for <pgsql-admin@postgresql.org>; Fri, 25 Mar 2011 05:50:06 -0300 (ADT)
Received: from smtp05.web.de  ( [172.20.4.166])
	by fmmailgate02.web.de (Postfix) with ESMTP id 5CC4919B1A01B
	for <pgsql-admin@postgresql.org>; Fri, 25 Mar 2011 09:50:05 +0100 (CET)
Received: from [91.66.178.84] (helo=[192.168.179.13])
	by smtp05.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #2)
	id 1Q32ib-0004yM-00
	for pgsql-admin@postgresql.org; Fri, 25 Mar 2011 09:50:05 +0100
Subject: Re: ERROR: could not access status of transaction
From: Stevie <stevieg@web.de>
To: pgsql-admin <pgsql-admin@postgresql.org>
In-Reply-To: <AANLkTims48njGKkvkXHiTG6=19hQ31VFmFRPPLg+5w03@mail.gmail.com>
References: <1300970362.2349.27.camel@stevie>
	<AANLkTims48njGKkvkXHiTG6=19hQ31VFmFRPPLg+5w03@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 25 Mar 2011 09:50:04 +0100
Message-ID: <1301043004.2357.8.camel@stevie>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Content-Transfer-Encoding: 7bit
X-Sender: stevieg@web.de
X-Provags-ID: V01U2FsdGVkX18YbeiV5M3svLhB0nIx76kH81GcwyIrXy87/iOf
	NazGldSRNOMn7N5A2h4oMBsfRi37iyNH8zn4O6rtG1wqvrygAG DMPFgiWZ4=
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, FREEMAIL_FROM=0.001, T_RP_MATCHES_RCVD=-0.01
X-Spam-Level: 
X-Archive-Number: 201103/239
X-Sequence-Number: 37111

Hello

> There is a commit log corruption in your database. 

Yes, and it seems this is produce by a pg_upgrade bug from pg8 to pg9 in
October 2010. 
> You need to make the files with right size (256K of zeroes).A suitable
> "dd" from /dev/zero will accomplish this on modernUnixen (ie, anything
> that has /dev/zero). Filling of those files with zeroes nothing but  "
> all those old transactions are aborted".

I was able to restore these files from backup. The dump is finished
without errors.

This corruption is just on our master replication, which was upgraded. 
Is it a good idea to restore the clog files there too?

Regards
Steffen