From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16577: Segfault on altering a table located in a dropped tablespace |
Date: | 2020-08-09 16:53:05 |
Message-ID: | 3064988.1596991985@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | 康桥平 | 2020-08-10 10:14:26 | a segfault failure of query |
Previous Message | Michael Paquier | 2020-08-09 13:20:54 | Re: BUG #16577: Segfault on altering a table located in a dropped tablespace |