On 12/18/2012 09:38 PM, Tom Lane wrote:
Andrew Dunstan <and...@dunslane.net> 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
Guys, thaaaaank youuu aaaall. :) reindex helped, did reindex on two
tables, and everything is now working like expected.
I will provide tomorrow all information which could help to understand
everything in detail, but now it's gonna be late in germany :). and i
got a headache of all this stuff ^^
Thanks so much!!!
--
Bernhard Schrader
System Administration
InnoGames GmbH
Harburger Schloßstraße 28 (Channel 4) - 21079 Hamburg - Germany
Tel +49 40 7889335-53
Fax +49 40 7889335-22
Managing Directors: Hendrik Klindworth, Eike Klindworth, Michael Zillmer
VAT-ID: DE264068907 Amtsgericht Hamburg, HRB 108973
http://www.innogames.com – bernhard.schra...@innogames.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
