On Thu, Apr 23, 2015 at 05:05:14PM +0200, Andres Freund wrote:
> On 2015-04-23 11:00:43 -0400, Bruce Momjian wrote:
> > On Thu, Apr 23, 2015 at 09:13:52AM -0400, Robert Haas wrote:
> > > 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 could just document that you need to pre-create the tablespace and
> ignore the resulting error. This isn't going to affect too many people.
This approach is going to cause any object in that tablespace to not
restore --- are we sure that enough people check for restore errors that
we will not have people losing data on a restore?
Also, the error is going to cause pg_upgrade to fail. We could have
pg_upgrade --check detect these cases and force people to fix their
setups before they run pg_upgrade --- at least that would be consistent
with the pg_dump behavior. Jim Nasby suggested throwing an error unless
IsBinaryUpgrade is set, and that would work, but it means we are
allowing such tablespaces to be upgraded using pg_upgrade only, which
seems kind of odd.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
