On Wed, Oct 21, 2020 at 06:54:17AM -0500, Justin Pryzby wrote:
> On Tue, Oct 20, 2020 at 09:17:22PM -0400, Tom Lane wrote:
> > Justin Pryzby writes:
> > > I wonder if pg_upgrade should try to rmdir() the tablespace dirs before
> > > restoring global objects, allowing it to succeed, rather than jus
On Tue, Oct 20, 2020 at 09:17:22PM -0400, Tom Lane wrote:
> Justin Pryzby writes:
> > I wonder if pg_upgrade should try to rmdir() the tablespace dirs before
> > restoring global objects, allowing it to succeed, rather than just "failing
> > early".
>
> I'm a little confused about that. If the d
Justin Pryzby writes:
> I wonder if pg_upgrade should try to rmdir() the tablespace dirs before
> restoring global objects, allowing it to succeed, rather than just "failing
> early".
I'm a little confused about that. If the directories aren't empty,
that will fail, but if they are, shouldn't th
On Thu, Oct 15, 2020 at 07:35:30PM -0400, Bruce Momjian wrote:
> On Fri, Oct 9, 2020 at 07:42:51PM -0400, Bruce Momjian wrote:
> > On Fri, Oct 9, 2020 at 02:23:10PM -0500, Justin Pryzby wrote:
> > > In my local branch, I had revised this comment to say:
> > >
> > > + * Note, v8.4 has no tablespa
On Thu, Oct 15, 2020 at 05:19:59PM -0700, Andres Freund wrote:
> Hi,
>
> On 2020-10-15 19:35:30 -0400, Bruce Momjian wrote:
> > On Fri, Oct 9, 2020 at 07:42:51PM -0400, Bruce Momjian wrote:
> > > On Fri, Oct 9, 2020 at 02:23:10PM -0500, Justin Pryzby wrote:
> > > > In my local branch, I had revi
Hi,
On 2020-10-15 19:35:30 -0400, Bruce Momjian wrote:
> On Fri, Oct 9, 2020 at 07:42:51PM -0400, Bruce Momjian wrote:
> > On Fri, Oct 9, 2020 at 02:23:10PM -0500, Justin Pryzby wrote:
> > > In my local branch, I had revised this comment to say:
> > >
> > > + * Note, v8.4 has no tablespace_suff
On Fri, Oct 9, 2020 at 07:42:51PM -0400, Bruce Momjian wrote:
> On Fri, Oct 9, 2020 at 02:23:10PM -0500, Justin Pryzby wrote:
> > 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 upg
On Fri, Oct 09, 2020 at 07:42:51PM -0400, Bruce Momjian wrote:
> On Fri, Oct 9, 2020 at 02:23:10PM -0500, Justin Pryzby wrote:
> > 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 upg
On Fri, Oct 9, 2020 at 02:23:10PM -0500, Justin Pryzby wrote:
> 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
> + *
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 be
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 fail
Added at
https://commitfest.postgresql.org/30/2739/
>From 831246aa6d6837b2b0da7c96ad2f44ffd6cd3951 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Thu, 24 Sep 2020 19:49:40 -0500
Subject: [PATCH v2] pg_upgrade --check to avoid tablespace failure mode
---
src/bin/pg_upgrade/check.c | 37 ++
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
13 matches
Mail list logo
