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 1pNMJV-0005ln-Rc for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Feb 2023 23:14:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pNMJT-0001ZH-HZ for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Feb 2023 23:14:47 +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 1pNMJT-0001Z2-8V for pgsql-hackers@lists.postgresql.org; Wed, 01 Feb 2023 23:14:47 +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 1pNMJM-0005Tp-V2 for pgsql-hackers@lists.postgresql.org; Wed, 01 Feb 2023 23:14:46 +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 311NEaQB1429054; Wed, 1 Feb 2023 18:14:36 -0500 From: Tom Lane To: Robert Haas cc: pgsql-hackers@lists.postgresql.org, Andrew Subject: Re: pg_dump versus hash partitioning In-reply-to: References: <1376149.1675268279@sss.pgh.pa.us> <1396807.1675275806@sss.pgh.pa.us> <1416220.1675285933@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Wed, 01 Feb 2023 16:52:30 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1429052.1675293276.1@sss.pgh.pa.us> Date: Wed, 01 Feb 2023 18:14:36 -0500 Message-ID: <1429053.1675293276@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Robert Haas writes: > On Wed, Feb 1, 2023 at 4:12 PM Tom Lane wrote: >> That being the case, I don't think moving the goalposts for hash >> function stability is going to lead to a workable solution. > I don't see that there is any easy, clean way to solve this in > released branches. The idea that I proposed could be implemented in > master, and I think it is the right kind of fix, but it is not > back-patchable. You waved your arms about inventing some new hashing infrastructure, but it was phrased in such a way that it wasn't clear to me if that was actually a serious proposal or not. But if it is: how will you get around the fact that any change to hashing behavior will break pg_upgrade of existing hash-partitioned tables? New infrastructure avails nothing if it has to be bug-compatible with the old. So I'm not sure how restricting the fix to master helps us. regards, tom lane