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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
