From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: tablespaces inside $PGDATA considered harmful |
Date: | 2015-04-23 13:13:52 |
Message-ID: | CA+TgmoZiCt5=4TRvLofhKWLkxphgsyPAGWueFn1bSgt+m9CzKQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 22, 2015 at 10:41 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> What is a real problem is that we don't block creating tablespaces
>> anywhere at all, including in obviously problematic places like the
>> transaction log directory:
>>
>> josh=# create tablespace tbl2 location '/home/josh/pg94/data/pg_xlog/';
>> CREATE TABLESPACE
>>
>> It really seems like we ought to block *THAT*. Of course, if we block
>> tablespace creation in PGDATA generally, then that's covered.
>
> 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-04-23 13:19:15 | Re: Allow SQL/plpgsql functions to accept record |
Previous Message | Andres Freund | 2015-04-23 12:51:21 | Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0 |