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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1
Дата
Msg-id 12525.1356019738@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1
Список pgsql-hackers
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.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Parser Cruft in gram.y
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Parser Cruft in gram.y