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 по дате отправления:

Предыдущее
От: John R Pierce
Дата:
Сообщение: Re: pg_top
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Set visibility map bit after HOT prune