| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, david(at)justatheory(dot)com, Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Subject: | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() |
| Date: | 2025-10-17 17:22:19 |
| Message-ID: | CAH2-WznLDZQHYj48H6bLSHw=eY9gP1jmB48_Ope=mPkzNH5DSQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Oct 17, 2025 at 1:15 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I don't have a problem with the change you made. I do have a problem
> with baza having spun up this check before we settled on a way to
> manage it.
+1.
> AFAIK we don't have any process by which we can decide
> that a reported ABI change is acceptable and then clear the failure.
> There was some discussion of how to control it [1], but nothing's been
> done yet.
The fact that this is now causing problems was entirely predictable
(and was in fact predicted). Having a way to suppress individual
warnings that are deemed to be invalid is 100% essential if we're
detecting ABI changes on a buildfarm animal like this.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ranier Vilela | 2025-10-17 17:28:21 | Re: Getting the SQLSTATE after a failed connection |
| Previous Message | Tom Lane | 2025-10-17 17:15:20 | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() |