From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | depesz(at)depesz(dot)com |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [GENERAL] pg_upgrade problem |
Date: | 2011-09-06 20:36:35 |
Message-ID: | 20829.1315341395@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2011-09-06 20:45:49 | Re: conditional insert |
Previous Message | hyelluas | 2011-09-06 19:06:43 | Advice on HA option |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-09-06 20:40:10 | Re: [v9.1] sepgsql - userspace access vector cache |
Previous Message | Simon Riggs | 2011-09-06 20:35:31 | Re: WAL "low watermark" during base backup |