Re: BUG #16577: Segfault on altering a table located in a dropped tablespace - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #16577: Segfault on altering a table located in a dropped tablespace
Date
Msg-id 3064988.1596991985@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #16577: Segfault on altering a table located in a dropped tablespace  (Michael Paquier <michael@paquier.xyz>)
List pgsql-bugs
Michael Paquier <michael@paquier.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.

Yeah, this seems like a mess.  DROP TABLESPACE supposes that it can
drop the tablespace if there are no physical files in it, and it's
really hard to see how it could test any more carefully given that
it cannot see what is in pg_class of other databases.

Offhand it seems like we could either

1. Start creating an empty physical file for each partitioned table
or index.

2. Forget the idea that a partitioned table/index has an associated
tablespace.

Neither of these are terribly attractive.  But I notice that we
already backed off the idea that this is a thing to some extent:

regression=# CREATE TABLE test_default_tab_p(id bigint, val bigint)
    PARTITION BY LIST (id) TABLESPACE pg_default;
ERROR:  cannot specify default tablespace for partitioned relations

I'm a bit inclined to think that this "feature" is sufficiently
broken that we should just drop it.

            regards, tom lane



pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #16577: Segfault on altering a table located in a dropped tablespace
Next
From: 康桥平
Date:
Subject: a segfault failure of query