Re: tablespaces inside $PGDATA considered harmful

On Thu, Apr 23, 2015 at 11:00 AM, Bruce Momjian <bruce@momjian.us> wrote:
>> > I have developed the attached patch to warn about creating tablespaces
>> > inside the data directory.  The case this doesn't catch is referencing a
>> > symbolic link that points to the same directory.  We can't make it an
>> > error so people can use pg_upgrade these setups.  This would be for 9.5
>> > only.
>>
>> I think this is a good thing to do, but I sure wish we could go
>> further and block it completely.  That may require more thought than
>> we have time to put in at this stage of the release cycle, though, so
>> +1 for doing at least this much.
>
> OK, good.  Thinking to 9.6, I am not sure how we could throw an error
> because we have allowed this in the past and pg_dump is going to be
> restored with a raw SQL CREATE TABLESPACE command.
>
> We have had this type of problem before, but never resolved it.  We
> almost need pg_dump to set a GUC variable telling the backend it is
> restoring a dump and issue a warning, but throw an error if the same
> command was issued outside of a pg_dump restore.  FYI, pg_upgrade
> already throws a warning related to the non-creation of a delete script.

Well, we've made backward-incompatible changes before.  Not to this
specific thing, but in general.  I don't think there's anything
preventing us from doing so here, except that we don't want to annoy
too many users.

I don't think the right solution is to add a GUC so that pg_dump
ignores this, and otherwise deny it.  It's bad if you do it as part of
a restore, and it's bad if you do it some other time, too.

What I'd recommend is that we add a GUC stupid_tablespaces=off.  If
you have done this in the past, and you want to upgrade (whether via
pg_dump or pg_upgrade) to a new release, you'll have to configure the
new cluster for stupid_tablespaces=on.  If you don't, you'll get an
error.  If you do, you'll get a warning.  That way, people can still
upgrade, but they have to set the GUC to make it work, so they'll be
clearly aware that they're doing something that is not recommended.

(Of course we might want to call the GUC something like other than
stupid_tablespaces, like allow_tablespaces_in_data_directory, but you
get the idea.)

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company