Date: Wed, 28 Oct 2020 10:40:45 -0300
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Michael Paquier <michael@paquier.xyz>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>,
	Tom Lane <tgl@sss.pgh.pa.us>, exclusion@gmail.com,
	pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16577: Segfault on altering a table located in a dropped
 tablespace
Message-ID: <20201028134045.GA6709@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20201028051821.GI28445@paquier.xyz>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On 2020-Oct-28, Michael Paquier wrote:

> On Thu, Oct 15, 2020 at 12:19:59PM -0300, Alvaro Herrera wrote:
> > It just dawned on me that a way to fix this is to use a pg_shdepend
> > entry to protect the tablespace from being dropped.
> 
> Haven't thought of that approach, good idea!  That would not be
> backpatchable but that would be a solution that does not require
> creating files where we don't need them.  Did you begin to look at
> that?

I haven't started on this one yet, but I intend to do so shortly.

Strictly speaking, we can still introduce a new category of pg_shdepend
entries in back branches; it won't break anything that works today.  And
while it won't fix the problem on existing partitioned tables, it is
possible to have users run a query on each database to create any rows
needed.  The only *actual* incompatibility is that once you upgrade and
create the rows, an older server of the same major may misbehave when
does rows are present.  But do we ever see users going back to previous
minors?  I think this isn't really a terrible problem in practice.  And
even if it is, users can work around it by deleting the offending rows.

What do you think?