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

On 2020-Aug-09, Tom Lane wrote:

> Michael Paquier <michael(at)paquier(dot)xyz> writes:
> > Thanks Alexander for the report. Interesting case indeed.
> > 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:

commit 807ae415c54628ade937cb209f0fc9913e6b0cf5
Author: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
AuthorDate: Fri Jan 4 14:51:17 2019 -0300
CommitDate: Fri Jan 4 14:51:17 2019 -0300

Don't create relfilenode for relations without storage

Some relation kinds had relfilenode set to some non-zero value, but
apparently the actual files did not really exist because creation was
prevented elsewhere. Get rid of the phony pg_class.relfilenode values.

Catversion bumped, but only because the sanity_test check will fail if
run in a system initdb'd with the previous version.

Reviewed-by: Kyotaro HORIGUCHI, Michael Paquier
Discussion: https://postgr.es/m/20181206215552.fm2ypuxq6nhpwjuc@alvherre.pgsql

But also fixing whatever *other* code was preventing creating of the
filenodes.

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. This seems necessary for branches 12 and 13, which have the
above commit, but not for 10/11 (which do have relfilenodes) nor master,
where we can revert it.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services