Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1
От | Bruce Momjian |
---|---|
Тема | Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1 |
Дата | |
Msg-id | 20121220182005.GJ20015@momjian.us обсуждение исходный текст |
Ответ на | Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Thu, Dec 20, 2012 at 11:08:58AM -0500, Tom Lane wrote: > Bruce Momjian <bruce@momjian.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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: