Re: BUG #16577: Segfault on altering a table located in a dropped tablespace

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> On 2020-Aug-09, Tom Lane wrote:
>> Michael Paquier <michael(at)paquier(dot)xyz> writes:
>>> For a normal table we would complain that the tablespace is not empty
>>> when attempting to drop the tablespace. But here we have only one
>>> partitioned table still holding references to the tablespace.

> Ah, so it turns out that the physical files were necessary after all.
> Maybe the solution to this problem is indeed to have them. It means
> partly reverting this commit:

I think actually the hardest part will be figuring out what is the
conversion path, e.g. will pg_upgrade have to know about this.

One point that strikes me is that that will put us in a place where
"does this relation have storage" is not a binary choice. The possible
answers will be "yes", "no", or "has an empty stub file". If we try
to take shortcuts rather than handling that honestly, we'll be in for
more bugs.

> As for the crash at hand, it seems it can be solved easily by making
> ruleutils avoid trying to dereference a null pointer, as in the attached
> patch.

Meh. I have a feeling that that's just the tip of the iceberg of
things that will go wrong in this scenario. I'm not sure how much
band-aid code we want to expend on the case --- after all, tablespace
create/drop is a superuser-only activity, so people aren't doing it
carelessly (one hopes).

regards, tom lane