From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(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 16:08:58 |
Message-ID: | 12525.1356019738@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert James | 2012-12-20 17:00:13 | Re: DONT_CARE Aggregate |
Previous Message | Richard Broersma | 2012-12-20 14:53:23 | Re: DONT_CARE Aggregate |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-12-20 16:10:03 | Re: Parser Cruft in gram.y |
Previous Message | Robert Haas | 2012-12-20 15:58:32 | Re: operator dependency of commutator and negator, redux |