Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Tl2w9-0002EI-AA for pgsql-hackers@arkaria.postgresql.org; Tue, 18 Dec 2012 19:34:45 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1Tl2w8-00077w-Cn for pgsql-hackers@arkaria.postgresql.org; Tue, 18 Dec 2012 19:34:44 +0000 Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Tl2w5-00074c-Fo for pgsql-hackers@postgresql.org; Tue, 18 Dec 2012 19:34:41 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Tl2w4-0007B9-9e for pgsql-hackers@postgresql.org; Tue, 18 Dec 2012 19:34:40 +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 qBIJYYMk012774; Tue, 18 Dec 2012 14:34:34 -0500 (EST) From: Tom Lane To: Andres Freund cc: Bernhard Schrader , Bruce Momjian , Andrew Dunstan , PostgreSQL-development Subject: Re: [ADMIN] Problems with enums after pg_upgrade In-reply-to: <20121218183916.GA7666@awork2.anarazel.de> 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> Comments: In-reply-to Andres Freund message dated "Tue, 18 Dec 2012 19:39:16 +0100" Date: Tue, 18 Dec 2012 14:34:33 -0500 Message-ID: <12773.1355859273@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-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Andres Freund 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers