Re: [ADMIN] Problems with enums after pg_upgrade - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [ADMIN] Problems with enums after pg_upgrade
Date
Msg-id 11487.1355855052@sss.pgh.pa.us
Whole thread Raw
In response to Re: [ADMIN] Problems with enums after pg_upgrade  (Bernhard Schrader <bernhard.schrader@innogames.de>)
Responses Re: [ADMIN] Problems with enums after pg_upgrade  (Andrew Dunstan <andrew@dunslane.net>)
Re: [ADMIN] Problems with enums after pg_upgrade  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
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 ...)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_basebackup from cascading standby after timeline switch
Next
From: Andrew Dunstan
Date:
Subject: Re: [ADMIN] Problems with enums after pg_upgrade