Message-ID: <50D0B7DB.101@dunslane.net>
Date: Tue, 18 Dec 2012 13:37:15 -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: 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>
In-Reply-To: <11487.1355855052@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 01:24 PM, Tom Lane wrote:
> Bernhard Schrader <bernhard.schrader@innogames.de> writes:
>> Beside of that, we tested a little bit more with the failing query:
>> The statement which is causing the error is a big UPDATE-statement with
>> FROM. After some testing we figured out that the subselect in the
>> FROM-clause is working fine. And if we simplify the UPDATE-statement
>> it's also working. We're able to show the data and we're able to do
>> simple updates on the table. But the two things combined are not
>> working.
> 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.
>
> If that is the answer, then reindexing said index would get rid of
> the problem (as well as all evidence that would help us find out how
> it happened ...)
>
> 			

Unless they can make a physical backup of the datadir first.

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