Re: [GENERAL] pg_upgrade problem
От | hubert depesz lubaczewski |
---|---|
Тема | Re: [GENERAL] pg_upgrade problem |
Дата | |
Msg-id | 20110907080741.GA9936@depesz.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] pg_upgrade problem (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
On Tue, Sep 06, 2011 at 09:21:02PM -0400, Bruce Momjian wrote: > Tom Lane wrote: > > hubert depesz lubaczewski <depesz@depesz.com> writes: > > > Worked a bit to get the ltree problem down to smallest possible, repeatable, situation. > > > > I looked at this again and verified that indeed, commit > > 8eee65c996048848c20f6637c1d12b319a4ce244 introduced an incompatible > > change into the on-disk format of ltree columns: it widened > > ltree_level.len, which is one component of an ltree on disk. > > So the crash is hardly surprising. I think that the only thing > > pg_upgrade could do about it is refuse to upgrade when ltree columns > > are present in an 8.3 database. I'm not sure though how you'd identify > > contrib/ltree versus some random user-defined type named ltree. > > It is actually easy to do using the attached patch. I check for the > functions that support the data type and check of they are from an > 'ltree' shared object. I don't check actual user table type names in > this case. While it will prevent failures in future, it doesn't solve my problem now :( Will try to do it via: - drop indexes on ltree - convert ltree to text - upgrade - convert text to ltree - create indexes on ltree Best regards, depesz
В списке pgsql-hackers по дате отправления: