Re: [GENERAL] pg_upgrade problem

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>
To: Bruce Momjian <bruce@momjian.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, depesz@depesz.com, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-09-07T18:43:19Z
Lists: pgsql-hackers

Attachments

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.

Attached patch applied to 9.0, 9.1, and HEAD.  Doc changes included.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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