Received-SPF: pass (mail127-ch1: domain of innogames.de designates
	157.56.252.5 as permitted sender) client-ip=157.56.252.5;
	envelope-from=bernhrad.schrader@innogames.de;
	helo=DB3PRD0310HT005.eurprd03.prod.outlook.com ; .outlook.com ;
Message-ID: <50D0DE1B.7040301@innogames.de>
Date: Tue, 18 Dec 2012 22:20:27 +0100
From: Bernhard Schrader <bernhard.schrader@innogames.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Andrew Dunstan <andrew@dunslane.net>, Andres Freund
	<andres@2ndquadrant.com>, Bruce Momjian <bruce@momjian.us>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [ADMIN] Problems with enums after pg_upgrade
References: <50CEFE95.9040301@innogames.de>
 <20121218014137.GB29143@momjian.us>
	<50D02D13.3010004@innogames.de> <50D0914E.3040508@dunslane.net>
	<20121218162256.GA24700@momjian.us> <50D0B0AD.9010905@innogames.de>
	<11487.1355855052@sss.pgh.pa.us>
	<20121218183916.GA7666@awork2.anarazel.de>
	<12773.1355859273@sss.pgh.pa.us> <50D0C80D.90806@dunslane.net>
	<13661.1355860724@sss.pgh.pa.us>
	<50D0CFF7.5030606@dunslane.net> <9230.1355863093@sss.pgh.pa.us>
In-Reply-To: <9230.1355863093@sss.pgh.pa.us>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 12/18/2012 09:38 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> People have been known to hack pg_enum on their own, especially before
>> we added enum extension.
>> Of course, if they do that they get to keep both pieces.
> Yeah ... this would be very readily explainable if there had been a
> manual deletion from pg_enum somewhere along the line.  Even if there
> were at that time no instances of the OID left in tables, there could
> be some in upper btree pages.  They'd have caused no trouble in 9.0
> but would (if odd) cause trouble in 9.2.
>
> Of course, this theory doesn't explain why the problem was seen on some
> copies and not others cloned from the same database --- unless maybe
> there had been an index page split on the master in between the
> clonings, and that moved the troublesome OID into a position where it
> was more likely to get compared-to.  That's not a hugely convincing
> explanation though.
>
> 			regards, tom lane
>

Guys, thaaaaank youuu aaaall. :) reindex helped, did reindex on two=20
tables, and everything is now working like expected.

I will provide tomorrow all information which could help to understand=20
everything in detail, but now it's gonna be late in germany :). and i=20
got a headache of all this stuff ^^

Thanks so much!!!

--=20
Bernhard Schrader
System Administration

InnoGames GmbH
Harburger Schlo=DFstra=DFe 28 (Channel 4) - 21079 Hamburg - Germany
Tel +49 40 7889335-53
Fax +49 40 7889335-22

Managing Directors: Hendrik Klindworth, Eike Klindworth, Michael Zillmer
VAT-ID: DE264068907 Amtsgericht Hamburg, HRB 108973

http://www.innogames.com =96 bernhard.schrader@innogames.de


--=20
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers