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 1mTmfP-00029H-DS for pgsql-hackers@arkaria.postgresql.org; Fri, 24 Sep 2021 14:59:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mTmfM-0004N3-7Y for pgsql-hackers@arkaria.postgresql.org; Fri, 24 Sep 2021 14:59:08 +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 1mTmfM-0004Mv-03 for pgsql-hackers@lists.postgresql.org; Fri, 24 Sep 2021 14:59:08 +0000 Received: from relay11.mail.gandi.net ([217.70.178.231]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mTmfE-0001tk-NS for pgsql-hackers@lists.postgresql.org; Fri, 24 Sep 2021 14:59:07 +0000 Received: (Authenticated sender: adsend@dunslane.net) by relay11.mail.gandi.net (Postfix) with ESMTPSA id F0584100006; Fri, 24 Sep 2021 14:58:54 +0000 (UTC) Subject: Re: pg_upgrade test for binary compatibility of core data types From: Andrew Dunstan To: Justin Pryzby , Jacob Champion Cc: tgl@sss.pgh.pa.us, peter.eisentraut@enterprisedb.com, pgsql-hackers@lists.postgresql.org, buschmann@nidsa.net, noah@leadboat.com, tomas.vondra@2ndquadrant.com, bruce@momjian.us, andres@anarazel.de References: <20210112041352.GY1849@telsasoft.com> <20210112171559.GO4320@momjian.us> <20210112172753.GC1849@telsasoft.com> <20210112175356.GP4320@momjian.us> <66753439-83ae-7be5-6e41-9537a6041a39@dunslane.net> <1575064.1615060903@sss.pgh.pa.us> <20210430183348.GQ27406@telsasoft.com> <20210912005116.GF26465@telsasoft.com> <30b2e19c-b44d-ec0a-6ea6-789b8e2be004@dunslane.net> <5d72f199-dc11-89a8-29d1-f20f9687c86f@dunslane.net> Message-ID: <83220c96-c2dd-fa42-ccc6-67dc0d848312@dunslane.net> Date: Fri, 24 Sep 2021 10:58:52 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <5d72f199-dc11-89a8-29d1-f20f9687c86f@dunslane.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 9/15/21 3:28 PM, Andrew Dunstan wrote: > On 9/13/21 9:20 AM, Andrew Dunstan wrote: >> On 9/12/21 2:41 PM, Andrew Dunstan wrote: >>> On 9/11/21 8:51 PM, Justin Pryzby wrote: >>>> @Andrew: did you have any comment on this part ? >>>> >>>> |Subject: buildfarm xversion diff >>>> |Forking https://www.postgresql.org/message-id/20210328231433.GI15100@telsasoft.com >>>> | >>>> |I gave suggestion how to reduce the "lines of diff" metric almost to nothing, >>>> |allowing a very small "fudge factor", and which I think makes this a pretty >>>> |good metric rather than a passable one. >>>> >>> Somehow I missed that. Looks like some good suggestions. I'll >>> experiment. (Note: we can't assume the presence of sed, especially on >>> Windows). >>> >>> >> I tried with the attached patch on crake, which tests back as far as >> 9.2. Here are the diff counts from HEAD: >> >> >> andrew@emma:HEAD $ grep -c '^[+-]' dumpdiff-REL9_* dumpdiff-REL_1* >> dumpdiff-HEAD >> dumpdiff-REL9_2_STABLE:514 >> dumpdiff-REL9_3_STABLE:169 >> dumpdiff-REL9_4_STABLE:185 >> dumpdiff-REL9_5_STABLE:221 >> dumpdiff-REL9_6_STABLE:11 >> dumpdiff-REL_10_STABLE:11 >> dumpdiff-REL_11_STABLE:73 >> dumpdiff-REL_12_STABLE:73 >> dumpdiff-REL_13_STABLE:73 >> dumpdiff-REL_14_STABLE:0 >> dumpdiff-HEAD:0 >> >> >> I've also attached those non-empty dumpdiff files for information, since >> they are quite small. >> >> >> There is still work to do, but this is promising. Next step: try it on >> Windows. >> >> > It appears to do the right thing on Windows. yay! > > > We probably need to get smarter about the heuristics, though, e.g. by > taking into account the buildfarm options and the platform. It would > also help a lot if we could make vcregress.pl honor USE_MODULE_DB. > That's on my TODO list, but it just got a lot higher priority. > > Here's what I've committed: cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com