From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Evan D(dot) Hoffman" <evandhoffman(at)gmail(dot)com>, Igor Neyman <ineyman(at)perceptron(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: [GENERAL] pg_upgrade fails, "mismatch of relation OID" - 9.1.9 to 9.2.4 |
Date: | 2013-05-09 21:29:02 |
Message-ID: | 20130509212902.GE24521@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Thu, May 9, 2013 at 05:11:43PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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...
Well, pg_upgrade operates in super-paranoid mode, so if we relax this,
it could potentially allow silent upgrade failures. I realize
eventually we will need to deal with this, but I would prefer to delay
that.
Also, I added code in PG 9.1 to allow the old/new clusters to have
identical OID layouts, so this would certainly complicate the code; see
info.c::gen_db_file_maps() for the check that is failing, and you can
see the 1:1 relationship. It was done in this commit:
commit 002c105a0706bd1c1e939fe0f47ecdceeae6c52d
Author: Bruce Momjian <bruce(at)momjian(dot)us>
Date: Sat Jan 8 13:44:44 2011 -0500
In pg_upgrade, remove functions that did sequential array scans looking
up relations, but rather order old/new relations and use the same array
index value for both. This should speed up pg_upgrade for databases
with many relations.
FYI, historically we have fixed TOAST table creation issues in pg_dump.
Evan, is the 9.1 cluster loaded into 9.1 or did you use pg_upgrade
previously to upgrade it _to_ 9.1?
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-05-09 21:40:49 | Re: LONG delete with LOTS of FK's |
Previous Message | Shaun Thomas | 2013-05-09 21:26:49 | Re: LONG delete with LOTS of FK's |
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2013-05-09 21:31:10 | Re: improving PL/Python builds on OS X |
Previous Message | Simon Riggs | 2013-05-09 21:22:34 | Re: corrupt pages detected by enabling checksums |