Re: tablespaces inside $PGDATA considered harmful

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: tablespaces inside $PGDATA considered harmful
Date: 2015-01-30 19:01:45
Message-ID: 54CBD519.8030502@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01/30/2015 09:19 AM, Stephen Frost wrote:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> Given all this, it seems like a good idea to at least give a warning
>> if somebody tries to create a tablespace instead the data directory.
>
> A warning seems like a good idea. I actually thought we *did* prevent
> it..
>
>> Arguably, we should prohibit it altogether, but there are obviously
>> people that want to do it, and there could even be somewhat valid
>> reasons for that, like wanting to set per-tablespace settings
>> differently for different tablespaces. Possibly we should prohibit it
>> anyway, or maybe there should be an option to create a tablespace
>> whose directory is a real directory, not a symlink. So then:
>>
>> CREATE TABLESPACE foo LOCATION '/home/rhaas/pgdata/pg_tblspc/foo';
>>
>> ...would fail, but if you really want a separate tablespace inside the
>> data directory, we could allow:
>>
>> CREATE TABLESPACE foo NO LOCATION;
>>
>> ...which would just create a bare directory where the symlink would normally go.
>
> I actually really like this 'NO LOCATION' idea. Are there reasons why
> that would be difficult or ill-advised to do?
>
> I could see the NO LOCATION approach being useful for migrating between
> systems, in particular, or a way to have pg_basebackup work that doesn't
> involve having to actually map all the tablespaces...

I like this idea too. And it would make tablespaces more manageable for
people who are using them for reasons other than putting them on
different disks.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2015-01-30 19:05:52 Re: Proposal: knowing detail of config files via SQL
Previous Message Andreas Karlsson 2015-01-30 18:26:28 Re: PATCH: Reducing lock strength of trigger and foreign key DDL