Re: Re: pg_upgrade fails: Mismatch of relation OID in database 8.4 -> 9.3
От | Bruce Momjian |
---|---|
Тема | Re: Re: pg_upgrade fails: Mismatch of relation OID in database 8.4 -> 9.3 |
Дата | |
Msg-id | 20140523185924.GA8484@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade fails: Mismatch of relation OID in database 8.4 -> 9.3 (David G Johnston <david.g.johnston@gmail.com>) |
Список | pgsql-hackers |
On Fri, May 23, 2014 at 06:28:28AM -0700, David G Johnston wrote: > Bruce Momjian wrote > > On Thu, May 22, 2014 at 09:20:38AM -0600, Jeff Ross wrote: > >> >I just tested ALTER TABLE in 8.4 and it does create a toast table for > >> >this case in 9.4: > >> > > >> > CREATE TABLE test (x CHAR(10)); > >> > ALTER TABLE test ALTER COLUMN x TYPE CHAR(8000); > >> > > >> I just tried this on the problem table and it did indeed create a > >> toast table. > >> > >> I then retried pg_upgrade and it failed with the same problem on a > >> different table in the same database. Of the 67 databases in the > >> 8.4 cluster, 5 (so far) have had this problem on at least one table. > > > > Yeah, it would be nice to be able to report all the problem tables, but > > I don't know how to do that except from pg_upgrade failing. Is there > > anything similar about these tables? > > Would a toast table in this situation have to be empty on the 8.4 database? > Is there some kind of stat table query that would identify all such toast > tables? Although it is possible some of those tables do indeed need a toast > table but never make use of it (especially if one makes judicious use of > unlimited text columns but never fills them with large amounts of data - > like for lookup tables). I don't see that as helping here. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
В списке pgsql-hackers по дате отправления: