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

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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-10 11:30:27
Message-ID: 20130510113027.GA4276@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On 2013-05-10 07:25:35 -0400, Bruce Momjian wrote:
> On Thu, May 9, 2013 at 06:19:31PM -0400, Bruce Momjian wrote:
> > > pg_upgrade already deals with the new code deciding not to create a
> > > toast table (by forcing it to do so anyway in binary upgrade mode).
> >
> > Yes, a good point I had forgotten. postgres --binary-upgrade mode can
> > force the toast table to be created to match the old cluster; see
> > toasting.c::create_toast_table():
> >
> > /*
> > * Check to see whether the table actually needs a TOAST table.
> > *
> > * If an update-in-place toast relfilenode is specified, force toast file
> > * creation even if it seems not to need one.
> > */
> > if (!needs_toast_table(rel) &&
> > (!IsBinaryUpgrade ||
> > !OidIsValid(binary_upgrade_next_toast_pg_class_oid)))
> > return false;
> >
> > > It's only the other case that's problematic -- but then AFAICS fixing
> > > that is just a SMOP.
> >
> > Yes, it is this opposite case where the _new_ cluster wants a TOAST
> > table that the old cluster doesn't have, which is what Evan is
> > reporting.
>
> So, if we eventually agree we need to be able to _suppress_ creation of
> the TOAST table on the new cluster, I propose we do it in a similar way
> to how we force TOAST creation, by having pg_dump set a backend variable
> that is then tested in the backend to suppress TOAST table creation.

I don't think disregarding the new clusters ideas about the requirement
of a toast table is a good idea; far too likely to cause problems in the
future.
So if there is a valid case where this can happen - which I am far from
sure from what I skimmed so far - we need a) a way to get a toast oid
that doesn't conflict with any of the oids in the old cluster b)
pg_upgrade then needs to accept that the new cluster might have more
toast rels than the old version.

> I don't think we know enough about the cause of this pg_upgrade failure
> to know if this is necessary.

True.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Chris Angelico 2013-05-10 13:00:06 Re: FATAL: database "a/system_data" does not exist
Previous Message Bruce Momjian 2013-05-10 11:25:35 Re: Re: [GENERAL] pg_upgrade fails, "mismatch of relation OID" - 9.1.9 to 9.2.4

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2013-05-10 12:39:10 Re: corrupt pages detected by enabling checksums
Previous Message Bruce Momjian 2013-05-10 11:25:35 Re: Re: [GENERAL] pg_upgrade fails, "mismatch of relation OID" - 9.1.9 to 9.2.4