Re: ABI Compliance Checker GSoC Project - Mailing list pgsql-hackers

From Mankirat Singh
Subject Re: ABI Compliance Checker GSoC Project
Date
Msg-id CAOtk82RrME_MY9oCie0TV=NKbuXM0B16c1U_oUpe4oE8BnpB6w@mail.gmail.com
Whole thread Raw
In response to Re: ABI Compliance Checker GSoC Project  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ABI Compliance Checker GSoC Project
Re: ABI Compliance Checker GSoC Project
List pgsql-hackers
On Sun, 13 Jul 2025 at 05:42, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Nitpick: I think something is backwards about the labeling.  AFAICS
> the described ABI change was made by 53cd0b71e not its predecessor
> 9dcc76414.  It does look like a useful bit of information once
> correctly attributed, though.
Thanks for pointing that out, I'll fix it!

> What we are going to want to know is if there are any ABI breaks in a
> stable branch since the last release point.  Once something turns up
> in that view, it'd be good to be able to drill down to exactly which
> commit(s) caused the changes.  But nobody is going to want to leaf
> through dozens or hundreds of per-commit reports, most of which should
> be totally uninteresting for this purpose (in a back branch anyway).
> Also, assuming we take action to undo the break, the cancelling-out
> commits are no longer interesting, but we want to ensure that indeed
> the ABI break is gone.  So in my mind, ABI diff between last release
> and branch tip is going to be the normal thing to want to see.
Got your point.
Here, I had a proposal: In case an ABI break is found, then loop
through the commits after the last run to find the offending commit.
We can also give the animal owner the option to decide whether they
want to use their own machine to perform this search or not. Let me
know your thoughts on this.

Regards,
Mankirat



pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)
Next
From: Dmitry Dolgov
Date:
Subject: Re: Changing shared_buffers without restart