Re: pg_upgrade 9.5 -> 9.6 fails when pg_largeobject is in separate tablespace

På søndag 09. oktober 2016 kl. 23:43:23, skrev Robert Haas <
robertmhaas(at)gmail(dot)com <mailto:robertmhaas(at)gmail(dot)com>>:
On Sat, Oct 8, 2016 at 9:02 AM, Andreas Joseph Krogh <andreas(at)visena(dot)com
<mailto:andreas(at)visena(dot)com>> wrote: (I've set allow_system_table_mods=on in
postgresql.conf)

Any configuration that includes this step is considered unsupported by the
PostgreSQL community.
 
It might be a good idea if we supported storing large objects in an alternate
tablespace, or in multiple tables in the same or different tablespaces. 
However, if you can only get there by enabling allow_system_table_mods, then we
don't.

 
Note that pg_largeobject can be moved without
changing allow_system_table_mods, namely by starting in single-user-mode, so I
really don't se why this is considered unsupported? 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.
 
AFAICT the very existence of pg_largeobject is an implementation-detail(and it
being a system-catalog considered a defect) so saying that by moving it
you're not able to use tools like pg_upgrade feels like being left out in the
cold...
 
Is fixing this in any plans? Is this something we can pay for getting fixed,
if so - what would it take?
 
PS: I cannot see this shortcoming being documented anywhere in pg_upgrade's
docs ( https://www.postgresql.org/docs/9.6/static/pgupgrade.html ), is it
mentioned anywhere?
 
-- 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>