Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hFgGs-0005MQ-6M for pgsql-hackers@arkaria.postgresql.org; Sun, 14 Apr 2019 14:38:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hFgGq-0004Zh-Sh for pgsql-hackers@arkaria.postgresql.org; Sun, 14 Apr 2019 14:38:12 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hFgGq-0004Za-H5 for pgsql-hackers@lists.postgresql.org; Sun, 14 Apr 2019 14:38:12 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hFgGn-0000v1-Ts for pgsql-hackers@lists.postgresql.org; Sun, 14 Apr 2019 14:38:11 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x3EEc5f3012679; Sun, 14 Apr 2019 10:38:05 -0400 From: Tom Lane To: David Rowley cc: Alvaro Herrera , PostgreSQL Hackers , Andres Freund Subject: Re: pg_dump is broken for partition tablespaces In-reply-to: References: <20190412233637.GA5173@alvherre.pgsql> <11955.1555251404@sss.pgh.pa.us> Comments: In-reply-to David Rowley message dated "Mon, 15 Apr 2019 02:25:06 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12677.1555252685.1@sss.pgh.pa.us> Date: Sun, 14 Apr 2019 10:38:05 -0400 Message-ID: <12678.1555252685@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk David Rowley writes: > On Mon, 15 Apr 2019 at 02:16, Tom Lane wrote: >> Well, it's not really nice perhaps, but you cannot just put in some >> other concrete tablespace OID instead. What a zero there means is >> "use the database's default tablespace", and the point of it is that >> it still means that after the DB has been cloned with a different >> default tablespace. If we don't store 0 then we break >> "CREATE DATABASE ... TABLESPACE = foo". > [ quotes documents ] I think those documentation statements are probably wrong in detail, or at least you're misreading them if you think they are justification for this patch. *This change will break CREATE DATABASE*. (And, apparently, the comment you tried to remove isn't sufficiently clear about that.) > Alvaro is proposing to change this behaviour for partitioned tables > and indexes. I'm proposing not having that special case and just > changing it. It's possible that Alvaro's patch is also broken, but I haven't had time to review it. The immediate question is what happens when somebody makes a partitioned table in template1 and then does CREATE DATABASE with a tablespace option. Does the partitioned table end up in the same tablespace as ordinary tables do? It's entirely possible BTW that this whole business of inheriting tablespace from the partitioned table is broken and should be thrown out. I certainly don't see any compelling reason for partitions to act differently from regular tables in this respect, and the more problems we find with the idea, the less attractive it seems. regards, tom lane