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 по дате отправления: