Re: [ADMIN] Problems with enums after pg_upgrade

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Bernhard Schrader <bernhard(dot)schrader(at)innogames(dot)de>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [ADMIN] Problems with enums after pg_upgrade
Date: 2012-12-18 20:38:13
Message-ID: 9230.1355863093@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Bernhard Schrader 2012-12-18 21:20:27 Re: [ADMIN] Problems with enums after pg_upgrade
Previous Message Andrew Dunstan 2012-12-18 20:20:07 Re: [ADMIN] Problems with enums after pg_upgrade

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2012-12-18 20:39:24 Re: Review of Row Level Security
Previous Message Robert Haas 2012-12-18 20:20:56 Re: logical decoding - GetOldestXmin