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

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

In response to

Responses

Browse pgsql-bugs by date

  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