On Thu, Apr 23, 2015 at 09:13:52AM -0400, Robert Haas wrote:
> On Wed, Apr 22, 2015 at 10:41 PM, Bruce Momjian <bruce@momjian.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.
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.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +