On Fri, Oct 09, 2020 at 02:53:25PM -0400, Bruce Momjian wrote:
> On Thu, Sep 24, 2020 at 07:55:31PM -0500, Justin Pryzby wrote:
> > This should be caught during --check, or earlier in the upgrade, rather than
> > only after dumping the schema.
> >
> > Typically, the tablespace dir would be left behind by a previous failed upgrade
> > attempt, causing a cascade of failured upgrades. I guess I may not be the only
> > one with a 3 year old wrapper which has a hack to check for this.
>
> This is an interesting failure case I never considered --- running
> pg_upgrade, having it fail, deleting and recreating the _new_ cluster
> directory, but not removing the new cluster's tablepace directories. I
> was able to recreate the failure, and verify that your patch properly
> throws an error during 'check' for this case.
>
> Modified patch attached. I plan to apply this to all supported Postgres
> versions.
Thanks for looking. It hits me a bunch of times every year.
> + * Check that tablespace directories do not already exist for new cluster.
> + * If they do, it would cause an error while restoring global objects.
> + * This allows the failure to be detected at check time, rather than
> + * during schema restore.
> + *
> + * Note, v8.4 has no tablespace_suffix, which is fine as long as the new
> + * cluster version has a suffix.
In my local branch, I had revised this comment to say:
+ * Note, v8.4 has no tablespace_suffix, which is fine so long as the version we
+ * being upgraded *to* has a suffix, since it's not allowed to pg_upgrade from
+ * a version to the same version if tablespaces are in use.
Cheers,
--
Justin
