Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rh7mC-009jAk-61 for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Mar 2024 12:50:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rh7mA-007gdT-G4 for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Mar 2024 12:50:38 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rh7mA-007gdK-6c for pgsql-hackers@lists.postgresql.org; Mon, 04 Mar 2024 12:50:38 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rh7m6-002nYQ-S3 for pgsql-hackers@lists.postgresql.org; Mon, 04 Mar 2024 12:50:37 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F013D5C006F; Mon, 4 Mar 2024 07:50:34 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 04 Mar 2024 07:50:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eisentraut.org; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:subject:subject:to:to; s=fm3; t=1709556634; x=1709643034; bh=tUSKl0AmQxDOLa9nJNKU2nLgkPG2CRVR r5o+JtGAKRk=; b=izjAvSJGjpz1YbXLmsC6qKtd6rCO7Nr8JZK2tbqeZCIf1SRb D0aYthQL7346wCdRz5AbaMmDjEY0caolwO6f744y263EZOT4PSThBcTTPT5btYVf Cw65RX59bKsgja8qDwNE7EL6e2IVwA1O7CEqf23Jowi4VsoNlulEh3x/M8CLlyLY 6Gl7ioGntwIt6ToXoxviTKnZmiFXtNRlI99c4qGVwgvuQhUaT5LO/h/SaAb/jDo0 +dKSpSZx45Q5WxvzWHzrQO+NN56PS5oXjzn9F1LS1hTtsjfK6ZS0rfJ/sYFWxjkc keMn9TEe9XVSC8nUMdxUyjYsHWHW+e3+wHEvSg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1709556634; x= 1709643034; bh=tUSKl0AmQxDOLa9nJNKU2nLgkPG2CRVRr5o+JtGAKRk=; b=J aNx/anJIgpFaZPJhYxBCcLlin440I2GbR+yChP8RkPjHdzk5O3r1ANtJuVg1maNb rsnXwX6KBX9izpuptGCDAguNVRtwYHopawja+xZPQLCLagB3IoOKGU1qzjzCHyOr B4WRJe6lFRTAn4lS3JsWr17DEntCd09oSJrizgkCJiqQUA1Agsc1l8iGsWaY6BMA EDIvbJ0030ad9sHB8AgJaNfJI34PIa/TIQVU8c06KkAXkz3RgoudUVQ9kqKwjGGZ YhCzrPp89a3egv3symB6uwhCNXQonPyo6nrIVLXHtP3RoOzLmXfVQ5mb4h4uD/QP VFROVdcuWuDtbBjI7iOVA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrheejgdegfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhesvghishgvnhhtrhgruhhtrdhorhhgqe enucggtffrrghtthgvrhhnpefgjedthfekfedtuefgieelheetleejgefhueeltdfhueet vdffudekfeejhfegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehpvghtvghrsegvihhsvghnthhrrghuthdrohhrgh X-ME-Proxy: Feedback-ID: ie0a040ee:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 4 Mar 2024 07:50:34 -0500 (EST) Message-ID: <1481f4f4-c563-47f7-ad0d-b656202e48bf@eisentraut.org> Date: Mon, 4 Mar 2024 13:50:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: abi-compliance-checker Content-Language: en-US To: Alvaro Herrera Cc: PostgreSQL Hackers References: <202402271325.uclbq77mroza@alvherre.pgsql> From: Peter Eisentraut In-Reply-To: <202402271325.uclbq77mroza@alvherre.pgsql> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 27.02.24 14:25, Alvaro Herrera wrote: > I like this idea and I think we should integrate it with the objective > of it becoming the workhorse of ABI-stability testing. However, I do > not think that the subsequent patches should be part of the tree at all; > certainly not the produced .xml files in your 0004, as that would be far > too unstable and would cause a lot of pointless churn. Looking at this again, if we don't want the .xml files in the tree, then we don't really need this patch series. Most of the delicate work in the 0001 patch was to find the right abidw options combinations to reduce the variability in the .xml output files (--no-show-locs is an obvious example). If we don't want to record the .xml files in the tree, then we don't need all these complications. For example, if we want to check the postgres backend ABI across minor versions, we could just compile it multiple times and compare the binaries directly: git checkout REL_16_0 meson setup build-0 meson compile -C build-0 git checkout REL_16_STABLE meson setup build-1 meson compile -C build-1 abidiff --no-added-syms build-0/src/backend/postgres build-1/src/backend/postgres > The way I see this working, is that we set up a buildfarm animal [per > architecture] that runs the new rules produced by the abidw option and > stores the result locally, so that for stable branches it can turn red > when an ABI-breaking change with the previous minor release of the same > branch is introduced. There's no point on it ever turning red in the > master branch, since we're obviously not concerned with ABI changes there. Maybe the way forward here is to write a buildfarm module for this, and then see from there what further needs there are.