Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Tl3vi-00039p-Da for pgsql-hackers@arkaria.postgresql.org; Tue, 18 Dec 2012 20:38:22 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1Tl3vh-0005RP-NM for pgsql-hackers@arkaria.postgresql.org; Tue, 18 Dec 2012 20:38:21 +0000 Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Tl3vg-0005RK-Kv for pgsql-hackers@postgresql.org; Tue, 18 Dec 2012 20:38:20 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Tl3vf-00085o-3Q for pgsql-hackers@postgresql.org; Tue, 18 Dec 2012 20:38:20 +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 qBIKcDQG009231; Tue, 18 Dec 2012 15:38:13 -0500 (EST) From: Tom Lane To: Andrew Dunstan cc: Andres Freund , Bernhard Schrader , Bruce Momjian , PostgreSQL-development Subject: Re: [ADMIN] Problems with enums after pg_upgrade In-reply-to: <50D0CFF7.5030606@dunslane.net> 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> Comments: In-reply-to Andrew Dunstan message dated "Tue, 18 Dec 2012 15:20:07 -0500" Date: Tue, 18 Dec 2012 15:38:13 -0500 Message-ID: <9230.1355863093@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 Andrew Dunstan 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers