Re: pg_upgrade 9.5 -> 9.6 fails when pg_largeobject is in separate tablespace - Mailing list pgsql-hackers
På søndag 09. oktober 2016 kl. 23:43:23, skrev Robert Haas <robertmhaas@gmail.com>:
On Sat, Oct 8, 2016 at 9:02 AM, Andreas Joseph Krogh <andreas@visena.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
Attachment
pgsql-hackers by date: