Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kz9Q4-00033b-9A for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Jan 2021 02:28:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kz9Q2-0004eE-3I for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Jan 2021 02:28:26 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kz9Q1-0004dz-TV for pgsql-hackers@lists.postgresql.org; Tue, 12 Jan 2021 02:28:25 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kz9Py-0006mo-IB; Tue, 12 Jan 2021 02:28:25 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 10C2SIUk1094035; Mon, 11 Jan 2021 21:28:18 -0500 From: Tom Lane To: Justin Pryzby cc: Alvaro Herrera , David Rowley , pgsql-hackers@lists.postgresql.org Subject: Re: pg_dump, ATTACH, and independently restorable child partitions In-reply-to: <20201204180231.GD24052@telsasoft.com> References: <20201024195949.GL9241@telsasoft.com> <20201107021835.GA13348@alvherre.pgsql> <20201120152055.GF24784@telsasoft.com> <577158.1606347319@sss.pgh.pa.us> <20201202225013.GJ24052@telsasoft.com> <2168110.1607101985@sss.pgh.pa.us> <20201204180231.GD24052@telsasoft.com> Comments: In-reply-to Justin Pryzby message dated "Fri, 04 Dec 2020 12:02:31 -0600" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1094033.1610418498.1@sss.pgh.pa.us> Date: Mon, 11 Jan 2021 21:28:18 -0500 Message-ID: <1094034.1610418498@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Justin Pryzby writes: > [ v5-0001-pg_dump-output-separate-object-for-ALTER-TABLE.AT.patch ] Pushed with mostly cosmetic edits. One thing I changed that isn't cosmetic is that I set the ArchiveEntry's owner to be the owner of the child table. Although we aren't going to do any sort of ALTER OWNER on this, it's still important that the owner be marked as someone who has the right permissions to issue the ALTER. The default case is that the original user will issue the ATTACH, which basically only works if you run the restore as superuser. It looks to me like you copied this decision from the INDEX ATTACH code, which is just as broken --- I'm going to go fix/backpatch that momentarily. Another thing that bothers me still is that it's not real clear that this code plays nicely with selective dumps, because it's not doing anything to set the dobj.dump field in a non-default way (which in turn means that the dobj.dump test in dumpTableAttach can never fire). It seems like it might be possible to emit a TABLE ATTACH object even though one or both of the referenced tables didn't get dumped. In some desultory testing I couldn't get that to actually happen, but maybe I just didn't push on it in the right way. I'd be happier about this if we set the flags with something along the lines of attachinfo->dobj.dump = attachinfo->parentTbl->dobj.dump & attachinfo->partitionTbl->dobj.dump; regards, tom lane