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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Groshev Andrey <greenx(at)yandex(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1
Date: 2012-12-20 18:20:05
Message-ID: 20121220182005.GJ20015@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Thu, Dec 20, 2012 at 11:08:58AM -0500, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > As you can see, ALTER INDEX renamed both the pg_constraint and pg_class
> > names. Is it possible someone manually updated the system table to
> > rename this primary key? That would cause this error message. The fix
> > is to just to make sure they match.
>
> > Does pg_upgrade need to be modified to handle this case? Are there
> > legitimate cases where they will not match and the index name will not
> > be preserved though a dump/restore? This seems safe:
>
> It's not always been true that ALTER INDEX would try to rename
> constraints to keep 'em in sync. A quick check says that only 8.3 and
> later do that. I'm not sure though how a 9.0 database could get into
> such a state without manual catalog hacking, since as you say a dump and
> reload should have ended up with the index and constraint having the
> same name again.
>
> I'd be inclined not to worry about this in pg_upgrade, at least not till
> we see a plausible scenario for the situation to arise without manual
> catalog changes.

Agreed. I added a C comment so we don't forget about the matching
requirement.

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

Browse pgsql-general by date

  From Date Subject
Next Message John R Pierce 2012-12-20 18:32:41 Re: Any experience with Drobo SAN and PG?
Previous Message Tom Lane 2012-12-20 17:36:47 Re: DONT_CARE Aggregate

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-12-20 18:30:48 Re: Set visibility map bit after HOT prune
Previous Message John R Pierce 2012-12-20 18:18:34 Re: pg_top