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 1v9qIO-009QGh-Om for pgsql-hackers@arkaria.postgresql.org; Fri, 17 Oct 2025 19:39:24 +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 1v9qIN-004fZP-IB for pgsql-hackers@arkaria.postgresql.org; Fri, 17 Oct 2025 19:39:22 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v9qIN-004fZH-8f for pgsql-hackers@lists.postgresql.org; Fri, 17 Oct 2025 19:39:22 +0000 Received: from mail-il1-x129.google.com ([2607:f8b0:4864:20::129]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v9qIK-002m2D-0D for pgsql-hackers@postgresql.org; Fri, 17 Oct 2025 19:39:21 +0000 Received: by mail-il1-x129.google.com with SMTP id e9e14a558f8ab-430c52703b3so14478995ab.1 for ; Fri, 17 Oct 2025 12:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760729958; x=1761334758; darn=postgresql.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=JFIcY2+gPd6hjokhg4E/8yJu9XHI+22NE6GS9nKWZxI=; b=BGKwUOmh5C5WC0enwzIRPSGB7pxR34mzPx2o2+uu4dVnmGcfRQrHxub25yWE/f4tFY Q+I3IaVUUCdkE0liQrQUM/DckvLl3L7peaw6X3ZUFz8roDTM8zdUrykTr04Z8i4gkTmx pOE4jM0T53UGVWGnXez0+cERwk5I5Nbt0kEh25qp79GZIs/YWsZicE0T3yfVPF56oiMz JwNbCwmumpkQLbFqXG8cth284jglkxmGfd+IvgnKyKgn3PTScFKa62K2MUHAo4FbDX5F UliA7L8yUc0vL6nkBtRvgow/HwELrl+vDlFNDAoxFhdY5mdDicfq0D8fCgwMooeJHxNA H8UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760729958; x=1761334758; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=JFIcY2+gPd6hjokhg4E/8yJu9XHI+22NE6GS9nKWZxI=; b=PSHnsAKQsrkH03f/xX1Ga9ozYU1bNlEejFaiobblvQiZ6kZh7m90kf4IWHj/kCHYuN ZR4NptmHPn20ywYBqblkgoxP/kfSlYXsdqQvOAsOjs2zXVzKWZIQGalXzL+kKlY4s7Wa sUO3BDAyjOOBWXRRLJ6HePXFZX88u5FeNPjM0Poaa7SvgoQ2duNZ66zlei9f+LDaZI86 zj07xp3zZzZjmauSdBL4hAtlqIAFaXAQ1CL53HtjAs6oUhsm5Gw5wjzVFXph8peSe7+A Kfreo2Zr6W3rNk8fbjpaNoS2nMTsWssE48OG7VC4k5Sj2obwq6MjR72DWKUFei/gI0Q4 z4Ig== X-Forwarded-Encrypted: i=1; AJvYcCWp/EwAetpYRq6S+O+T187USvBfqRTHaISw1Nrfo2FUsZFfpFMQ4VhVQGRtIOaDb4b6OdEUHTqyoQgGjheY@postgresql.org X-Gm-Message-State: AOJu0YzzgsEcq8D47JC9qZSylojtmwfE3VQ9UZLHmOUPtJCvrsecUQHK p5LnRImd51sXlWrLCBkCG54oTz67zk9p8mELRkB66csFt76oXqzWz5JZ X-Gm-Gg: ASbGncsYm7akInHEbRPVI3/zhLH7HaNIAOzZIfTnGajfljJhE7vCf0xp3cTIQ3TZ6BA KhMgKuIbZwm0jKmgiVga8SNAdOi5eHP8ffetZdeMI2EQKrua6L6WEqSlph5745G7myC3sPax2Mp tb40Gz13zrP/MpMnrpNWiHR9kHaL+WwnewSE5upDe1vce5f6tqmToz/c8rFzY8ObiFbYhuzMlEN sMkEEr2TpjJ5DOP5LnbmRbzdFw/5fWnzWOjf3wXrglVMMqGT8SVSFTXenUODgmAftzVDYGLf6ro iQLj/SoT41Ci2vElDRrhwRtGrip+Hav4FFof/bpX0QSFdtfL4kML7mgkKvsy/jSPyaVFo9kyAWf riqk+AchUMTFoMH8crJZ2VuRWbmIStygZFL9MRBCtb6WYntAskBUUCYEXb8k0S1vGCGrGAw1d9f BoLZfaT9jGENYsoGEGWXJPY2vgqdZlFNlU1itCSB9hUcphMXrkE7siCvjt7CSwaRX9Lw== X-Google-Smtp-Source: AGHT+IG2+yfRE29aOE9qVGGJwAyVgfgfjTIumTFp7RmhqGLG94ESph0OCRawcjK38pRMP86i14CK/A== X-Received: by 2002:a92:c247:0:b0:430:cecb:9e77 with SMTP id e9e14a558f8ab-430cecb9f08mr26083545ab.27.1760729957925; Fri, 17 Oct 2025 12:39:17 -0700 (PDT) Received: from nathan (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-430d07cb51esm2426915ab.37.2025.10.17.12.39.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Oct 2025 12:39:17 -0700 (PDT) Date: Fri, 17 Oct 2025 14:39:15 -0500 From: Nathan Bossart To: Peter Geoghegan Cc: Tom Lane , pgsql-hackers@postgresql.org, david@justatheory.com, Andrew Dunstan Subject: Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() Message-ID: References: <1713509.1760721320@sss.pgh.pa.us> <1723302.1760726712@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Oct 17, 2025 at 03:33:28PM -0400, Peter Geoghegan wrote: > On Fri, Oct 17, 2025 at 3:28 PM Nathan Bossart wrote: >> I was imagining this working more like what Tom suggested. IOW we'd use >> the latest commit listed in the file (perhaps always the first one) as the >> baseline. > > You said "I suppose this idea is entirely dependent on the maintainers > of the abi-compliance-check code to adapt to it", which I understood > to mean that you thought that the upstream tool would somehow be made > to accept these kinds of ignore files. Obviously I misunderstood. Sorry, I wasn't clear there. >> Of course, this doesn't work too well if we have a bunch of ABI >> breaks between buildfarm checks. But my guess is that we could deal with >> that pretty easily (e.g., make sure the buildfarm member in question runs >> for every commit on the stable branch). > > In practice I think that it would be up to the person writing the next > suppression to verify that there were no unrelated changes in the > interim between their new blessed/suppression commit and the prior > one. That doesn't seem super onerous to me, given that even false > positives don't seem to be all that common with > abi-compliance-checker. Agreed. Even if someone forgets to do that validation, the chances of missing something seem low. -- nathan