pg_upgrade not able to cope with pg_largeobject being in a different tablespace

From: Andreas Joseph Krogh <andreas(at)visena(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: pg_upgrade not able to cope with pg_largeobject being in a different tablespace
Date: 2016-10-13 08:14:08
Message-ID: VisenaEmail.13.cecf0de17d70ca2c.157bd129896@tc7-visena
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi all.
 
(I tried raising this on -hackers but got "this is not supported"-answer,
which is quite dissatisfactory..)
 
I have an issue with pg_upgrade upgrading 9.5 to 9.6. (my system is
Ubuntu-16.04 and packages from http://apt.postgresql.org/)
<http://apt.postgresql.org/)>
 
In short pg_upgrade fails with:
 
Linking user relation files
No match found in new cluster for old relation with OID 16388 in database
"andreak": "pg_toast.pg_toast_2613" which is the TOAST table for
"pg_catalog.pg_largeobject"
No match found in new cluster for old relation with OID 16390 in database
"andreak": "pg_toast.pg_toast_2613_index" which is an index on
"pg_toast.pg_toast_2613" which is the TOAST table for
"pg_catalog.pg_largeobject"
Failed to match up old and new tables in database "andreak"
Failure, exiting
 
I issued the following command:
PG_NEW_VERSION=9.6
PG_OLD_VERSION=9.5
/usr/lib/postgresql/$PG_NEW_VERSION/bin/pg_upgrade \
          --old-bindir=/usr/lib/postgresql/$PG_OLD_VERSION/bin/ \
          --new-bindir=/usr/lib/postgresql/$PG_NEW_VERSION/bin/ \
          --old-datadir=/var/lib/postgresql/$PG_OLD_VERSION/main \
          --new-datadir=/var/lib/postgresql/$PG_NEW_VERSION/main \
          -o " -c
config_file=/etc/postgresql/$PG_OLD_VERSION/main/postgresql.conf" \
          -O " -c
config_file=/etc/postgresql/$PG_NEW_VERSION/main/postgresql.conf" \
          --link

 
 
My database and tablespaces are created like this:
I have tablespaces configured outside PGDATA:
mkdir /var/lib/postgresql/9.5/tablespaces/andreak
mkdir /var/lib/postgresql/9.5/tablespaces_lo/andreak
psql -c "create tablespace andreak OWNER andreak location
'/var/lib/postgresql/9.5/tablespaces/andreak'" postgres;
psql -c "create tablespace andreak_lo OWNER andreak location
'/var/lib/postgresql/9.5/tablespaces_lo/andreak'" postgres;
createdb --tablespace=andreak -O andreak andreak

psql -U postgres -c "alter table pg_largeobject set tablespace andreak_lo" -d
andreak

(I've set allow_system_table_mods=on in postgresql.conf)
 
These are symlinked:
ln -s /storage/wal/9.5/pg_xlog /var/lib/postgresql/9.5/main/pg_xlog
ln -s /storage/fast_ssd/9.5/tablespaces /var/lib/postgresql/9.5/tablespaces
ln -s /storage/archive_disk/9.5/tablespaces_lo
/var/lib/postgresql/9.5/tablespaces_lo

 
I would assume that having pg_largeobject in a separate tablespace is more and
more common these days, having real-cheap SAN vs. fast-SSD for normal
tables/indexes/wal.
 
So - I'm wondering if we can fund development of pg_upgrade to cope with this
configuration or somehow motivate to getting this issue fixed?
 
Would any of the PG-companies (2ndQ, EDB, PgPro) take a stab at this?
 
Any feedback welcome, thanks.
 

-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andreas(at)visena(dot)com <mailto:andreas(at)visena(dot)com>
www.visena.com <https://www.visena.com>
<https://www.visena.com>

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alvaro Herrera 2016-10-13 10:00:40 Re: MultiXact member wraparound protections are disabled
Previous Message Thomas Munro 2016-10-13 03:46:30 Re: SERIALIZABLE and INSERTs with multiple VALUES