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 1k5zFP-0001aS-Uz for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Aug 2020 22:29:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1k5zFO-0002VZ-SZ for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Aug 2020 22:29: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 1k5zFO-0002VS-LI for pgsql-hackers@lists.postgresql.org; Wed, 12 Aug 2020 22:29:26 +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 1k5zFI-0006AO-DI for pgsql-hackers@lists.postgresql.org; Wed, 12 Aug 2020 22:29:26 +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 07CMTGBM324386; Wed, 12 Aug 2020 18:29:16 -0400 From: Tom Lane To: Andres Freund cc: Alvaro Herrera , pgsql-hackers@lists.postgresql.org Subject: Re: Dependencies for partitioned indexes are still a mess In-reply-to: <20200812221313.zfqsfcpt2tmkv4la@alap3.anarazel.de> References: <3170626.1594842723@sss.pgh.pa.us> <20200812221313.zfqsfcpt2tmkv4la@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Wed, 12 Aug 2020 15:13:13 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <324384.1597271356.1@sss.pgh.pa.us> Date: Wed, 12 Aug 2020 18:29:16 -0400 Message-ID: <324385.1597271356@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Andres Freund writes: > I've attached the diff between first.sql and second.sql. Here's the > highlights: As I recall, the differences in b_star etc are expected, because pg_dump reorders that table's columns to match its inheritance parent, which they don't to start with because of ALTER TABLE operations. I'm pretty sure we set it up that way deliberately ages ago, because pg_dump used to have bugs when contending with such cases. Not sure about a good way to mechanize recognizing that these diffs are expected. Dunno about test_type_diff2, but it might be a newer instance of the same thing. regards, tom lane