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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #16577: Segfault on altering a table located in a dropped tablespace
Дата
Msg-id 3064988.1596991985@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #16577: Segfault on altering a table located in a dropped tablespace  (Michael Paquier <michael@paquier.xyz>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: BUG #16577: Segfault on altering a table located in a dropped tablespace
Следующее
От: 康桥平
Дата:
Сообщение: a segfault failure of query