Re: [GENERAL] pg_upgrade problem

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

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.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Attachment Content-Type Size
/rtmp/pg_upgrade text/x-diff 3.9 KB

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2011-09-07 01:22:36 Re: Which perl works with pg9.1
Previous Message Craig Ringer 2011-09-07 00:58:29 Re: Which perl works with pg9.1

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-09-07 01:43:15 Re: Back branch update releases this week; beta postponed
Previous Message Peter Geoghegan 2011-09-07 01:14:18 Re: Large C files