Re: [GENERAL] pg_upgrade problem

From: hubert depesz lubaczewski <depesz(at)depesz(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] pg_upgrade problem
Date: 2011-09-07 08:07:41
Message-ID: 20110907080741.GA9936@depesz.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Tue, Sep 06, 2011 at 09:21:02PM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > hubert depesz lubaczewski <depesz(at)depesz(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jayadevan M 2011-09-07 08:24:52 Re: Complex query question
Previous Message Jeff Davis 2011-09-07 07:15:14 Re: Disconnecting and cancelling a statement

Browse pgsql-hackers by date

  From Date Subject
Next Message daveg 2011-09-07 09:16:34 Re: FATAL: lock AccessShareLock on object 0/1260/0 is already held
Previous Message Pavan Deolasee 2011-09-07 07:05:07 Re: REVIEW Single pass vacuum - take 2