Message-ID: <50D0C80D.90806@dunslane.net>
Date: Tue, 18 Dec 2012 14:46:21 -0500
From: Andrew Dunstan <andrew@dunslane.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Andres Freund <andres@2ndquadrant.com>,
	Bernhard Schrader <bernhard.schrader@innogames.de>,
	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>
In-Reply-To: <12773.1355859273@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


On 12/18/2012 02:34 PM, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
>> On 2012-12-18 13:24:12 -0500, Tom Lane wrote:
>>> Does the table being updated have any indexes on enum columns?  I'm
>>> suspicious that the bogus OID is in an index page somewhere, and not
>>> in the table at all.
>> I already wondered whether it could be a problem caused by pg_upgrade
>> not ignoring invalid indexes until recently, but I don't really see how
>> it could cause an invalid oid to end up in the index.
> It seems like this might indicate a flaw in our scheme for preventing
> uncommitted enum values from getting into tables/indexes.  Hard to see
> what though.
>
> Bernhard, if you do identify a particular index as being the source of
> the failure, that would at least tell us for sure which enum type is
> at fault.  I don't suppose you would have any info about the history
> of that enum type in your database?  The fact that the OID is odd
> implies that it belonged to a value that was added by ALTER TYPE ADD
> VALUE, but what we'd want is some context around any past uses of
> that command, especially if they failed or were rolled back.
>
> 			


He's upgrading from 9.0, which didn't have enum extension at all, and 
where odd enums didn't mean anything special.

cheers

andrew


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