On Tue, Sep 06, 2011 at 09:21:02PM -0400, Bruce Momjian wrote: > Tom Lane wrote: > > hubert depesz lubaczewski <dep...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
