(Forgot to CC pgsql-bugs.)
Jason
----- Forwarded message from postgres@jasonk.me -----
Date: Tue, 24 Mar 2020 14:24:33 -0700
From: postgres@jasonk.me
To: Andres Freund <andres@anarazel.de>
Subject: Re: handle tablespaces for partitioned tables during ALTER DATABASE
Message-ID: <20200324212433.3knuzvcpc3idjm2b@jasonk.me>
References: <20200324062608.dstxvn7zmnpmplxr@jasonk.me>
<20200324192359.yw7q5rlfqqxoktl6@alap3.anarazel.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200324192359.yw7q5rlfqqxoktl6@alap3.anarazel.de>
Hi, Andres.
On 2020-03-24T12:23:59-0700, Andres Freund wrote:
> I don't immediately see what problem this could cause? There's no
> physical file associated with a partitioned table, it's "just" a
> template for new partitions of that partitioned table.
I had illustrated a plausible scenario where this could be _unexpected_. The
state that you can get into after the first `ALTER DATABASE` is strange because
the tablespace of `scores_rank_0_to_100` is not `InvalidOid` yet equal to the
database's tablespace.
You can't get into this state normally: try
```sql
CREATE DATABASE f TABLESPACE fast;
\c f
CREATE TABLE t (i int, j int) PARTITION BY RANGE (i);
CREATE TABLE t0 PARTITION OF t FOR VALUES FROM (0) TO (100) TABLESPACE fast;
SELECT relname, reltablespace FROM pg_class WHERE relname LIKE 't0';
```
```
relname | reltablespace
---------+---------------
t0 | 0
(1 row)
```
Notice that it's `InvalidOid`, not the explicit database's tablespace. But you
can get into that state with some work, like I illustrated in my example in the
first message.
For less confusion, I think it makes sense to prohibit this or seamlessly
convert the appropriate `reltablespace` values to `InvalidOid`. Enforcing this
may also give me less things to worry about for my own work.
Jason
----- End forwarded message -----