Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Groshev Andrey <greenx(at)yandex(dot)ru>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1
Date: 2012-12-18 21:18:41
Message-ID: 20121218211841.GD24700@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Tue, Dec 18, 2012 at 09:34:53PM +0400, Groshev Andrey wrote:
> later in the log pg_dump, I found the definition of "new rel"
>
> --
> -- Name: plob.ВерсияВнешнегоДокумента$Документ; Type: CONSTRAINT; Schema: public; Owner: postgres; Tablespace:
> --
>
> ALTER TABLE ONLY "lob.ВерсияВнешнегоДокумента$Документ"
> ADD CONSTRAINT "plob.ВерсияВнешнегоДокумента$Документ" PRIMARY KEY ("@Файл", "Страница");
>
>

Can you post the full definition of the table on this public email list?
Also, why did the error think this was in the public schema? Any idea?

---------------------------------------------------------------------------

>
>
> 18.12.2012, 19:38, "Bruce Momjian" <bruce(at)momjian(dot)us>:
> > On Mon, Dec 17, 2012 at 09:21:59PM -0500, Bruce Momjian wrote:
> >
> >>>  Mismatch of relation names: database "database", old rel public.lob.ВерсияВнешнегоДокумента$Документ_pkey, new rel public.plob.ВерсияВнешнегоДокумента$Документ
> >>>  Failure, exiting
> >
> > I am now confused over the error message above.  This is the code that
> > is generating the error:
> >
> >         /*
> >          * TOAST table names initially match the heap pg_class oid.
> >          * In pre-8.4, TOAST table names change during CLUSTER; in pre-9.0,
> >          * TOAST table names change during ALTER TABLE ALTER COLUMN SET TYPE.
> >          * In >= 9.0, TOAST relation names always use heap table oids, hence
> >          * we cannot check relation names when upgrading from pre-9.0.
> >          * Clusters upgraded to 9.0 will get matching TOAST names.
> >          */
> >         if (strcmp(old_rel->nspname, new_rel->nspname) != 0 ||
> >             ((GET_MAJOR_VERSION(old_cluster.major_version) >= 900 ||
> >               strcmp(old_rel->nspname, "pg_toast") != 0) &&
> >              strcmp(old_rel->relname, new_rel->relname) != 0))
> >             pg_log(PG_FATAL, "Mismatch of relation names: database \"%s\", "
> >                    "old rel %s.%s, new rel %s.%s\n",
> >                    old_db->db_name, old_rel->nspname, old_rel->relname,
> >                    new_rel->nspname, new_rel->relname);
> >
> > Looking at the Russian, I see 'old rel' public.lob.* and 'new rel'
> > public.plob.*.  I assume the database is called 'database', and the
> > schema is called 'public', but what is 'lob' and 'plob'?  If those are
> > tables or indexes, what is after the period?  Do you have periods
> > embedded in the table/index names?  That is certainly possible, but not
> > common, e.g.:
> >
> >         test=> create table "test.x" (y int);
> >         CREATE TABLE
> >
> > Is the schema called "public.lob"?  I expected to see schema.objname.
> >
> > --
> >   Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
> >   EnterpriseDB                             http://enterprisedb.com
> >
> >   + It's impossible for everything to be true. +

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message News Subsystem 2012-12-18 23:15:42
Previous Message Rhys A.D. Stewart 2012-12-18 19:31:42 can one speed up a custom aggregate by using native ones

Browse pgsql-hackers 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 Jeff Davis 2012-12-18 20:52:25 Re: Enabling Checksums