På torsdag 13. oktober 2016 kl. 16:09:34, skrev Bruce Momjian <br...@momjian.us 
On Thu, Oct 13, 2016 at 10:14:08AM +0200, Andreas Joseph Krogh wrote:
 > I would assume that having pg_largeobject in a separate tablespace is more 
 > more common these days, having real-cheap SAN vs. fast-SSD for normal 
 > indexes/wal.

 So common that no one has ever asked for this feature before?
Sometimes one gets the feeling that one is the only one in the universe doing 
something one considers "quite common":-)
> 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.

 You would need to get buy-in that that community wants the relocation of
 pg_largeobject to be supported via an SQL command, and at that point
 pg_upgrade would be modified to support that.  It is unlikely pg_upgrade
 is going to be modified to support something that isn't supported at the
 SQL level.  Of course, you can create a custom version of pg_upgrade to
 do that.
Doesn't "ALTER TABLE pg_largeobject SET TABLESPACE myspace_lo" count as being 
"at the SQL-level"?
The whole problem seems to come from the fact that BLOBs are stored in 
pg_largeobject which for some reason is implemented as a system-catalogue in 
PG, which imposes all kinds of weird problems, from a DBA-perspective.
Can we pay you at EDB for making such a custom version of pg_upgrade for 9.6?
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com <mailto:andr...@visena.com>
www.visena.com <https://www.visena.com>


Reply via email to