Re: [GENERAL] pg_upgrade problem
hubert depesz lubaczewski <depesz@depesz.com>
From: hubert depesz lubaczewski <depesz@depesz.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-09-07T08:07:41Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
ltree support for multibyte encodings. Patch was made by
- 8eee65c99604 8.4.0 cited
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