Re: Re: [GENERAL] pg_upgrade fails, "mismatch of relation OID" - 9.1.9 to 9.2.4 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [GENERAL] pg_upgrade fails, "mismatch of relation OID" - 9.1.9 to 9.2.4
Date
Msg-id 3455.1368133903@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] pg_upgrade fails, "mismatch of relation OID" - 9.1.9 to 9.2.4  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Re: [GENERAL] pg_upgrade fails, "mismatch of relation OID" - 9.1.9 to 9.2.4  (Bruce Momjian <bruce@momjian.us>)
Re: [GENERAL] pg_upgrade fails, "mismatch of relation OID" - 9.1.9 to 9.2.4  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> OK, that's progress.  Having received the table schema privately via
> email, I see several 'character varying(40)' fields in the schema.  So
> the question is how was this table able to get away without a TOAST
> table in 9.1, while 9.2 created one for an empty table?  Ideas?

AFAICT the needs_toast_table() logic is identical between 9.1 and 9.2,
so it seems like it must have something to do with an odd ALTER TABLE
history in the source database.  It's hard to think what, however.

In any case, it seems like pg_upgrade ought to have a strategy for
dealing with tables acquiring toast tables like this, since if we
ever do tweak the needs_toast_table() logic, or for instance do
something like deciding to support 6-byte UTF8 codes, we're going
to face such cases.  I dunno exactly how we might deal with it though...

BTW, Evan, which encoding is in use in this DB?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: improving PL/Python builds on OS X
Next
From: Simon Riggs
Date:
Subject: Re: corrupt pages detected by enabling checksums