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

On Mon, Aug 10, 2020 at 02:59:26PM -0400, Tom Lane wrote:
> 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.

Hmm. Creating a file for partitioned table would be a completely new
thing as well. heap_create() has never created a file for partitioned
tables since 10 so this could open to a new class of 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).

+1. I would suspect that it is not the only code path that would run
into issues.
--
Michael