Re: Move pg_largeobject to a different tablespace *without* turning on system_table_mods.

From: Andreas Joseph Krogh <andreas(at)visena(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Move pg_largeobject to a different tablespace *without* turning on system_table_mods.
Date: 2016-10-18 14:51:54
Message-ID: VisenaEmail.70.769d44540d145b81.157d840696b@tc7-visena
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

På tirsdag 18. oktober 2016 kl. 16:26:37, skrev Euler Taveira <
euler(at)timbira(dot)com(dot)br <mailto:euler(at)timbira(dot)com(dot)br>>:
On 18-10-2016 10:13, Andreas Joseph Krogh wrote:
> From time to time pg_largeobject comes up as an issue with being
> implemented as a system-catalog.

Did you read the archives [1]?
 
 
Yes..
 
> As I see it, there are 2 relevant use-cases for improving the situation:
> 1. Being able to pg_dump *without* any LOs (think of it as
>    without the contents of pg_largeobject). This is very handy
>    for testing/troubleshooting.
>
It could be an option (--no-blobs). The -b option has a limited use case.
 
 
Yes, it definitely should be an option to pg_dump. I guess because of
pg_largeobject being a system-catalog it adds additional difficulties
implementing it?
 
> 2. Being able to move pg_largeobject to a different tablespace
>    *without* turning on system_table_mods. This is important for
>    people storing LOTS of large-objects on separate
>    disks (non-SSD) and hence in a different tablespace.
> Anyone willing to discuss this?

This was proposed a few years ago but no one cared to draft a patch.
 
So that why I'm re-raising the issue:-)
Having "everything in the database" adds lots of benefits, conceptually
(follows tx-semantics, consistent backups etc.), however it's currently not so
easy in practice.
 
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>

 

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-10-18 14:55:39 Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1
Previous Message Tom Lane 2016-10-18 14:40:55 Re: Query cancel seems to be broken in master since Oct 17