On Sep 12, 2025, at 13:53, Tom Lane wrote:
> That seems substantially more complicated than just moving which
> commit is considered the baseline. It might be less reliable too:
> if the exclusions are written sloppily, they might hide problems
> we'd rather find out about. (I do not regard val
On Sep 12, 2025, at 10:37, Peter Eisentraut wrote:
> This was a change that was intentionally backpatched in a different way in
> order to preserve ABI compatibility. Compare commits 344662848ac on
> REL_18_STABLE and 0b934d3994f on REL_17_STABLE. So everything is in order. :)
Excellent! But
On 2025-Sep-12, Tom Lane wrote:
> My concern is that when we get a report, we might decide to apply
> some fix to remove the ABI delta, or we might decide it's intentional
> and/or harmless and leave the code as-is. In the latter case, the
> ABI-checking BF animal(s) will be red until the next re
=?utf-8?Q?=C3=81lvaro?= Herrera writes:
> On 2025-Sep-12, Tom Lane wrote:
>> My concern is that when we get a report, we might decide to apply
>> some fix to remove the ABI delta, or we might decide it's intentional
>> and/or harmless and leave the code as-is.
> The solution I propose for this (w
Peter Eisentraut writes:
> On 12.09.25 16:52, David E. Wheeler wrote:
>> Excellent! But an example like this presumably helps make Tom’s case that
>> each branch could have a file that suggests which commit to use as the base
>> for comparison, so that in this example it could be set to 34466284
On 08.09.25 17:17, David E. Wheeler wrote:
The RC1 change surprised me a little; here’s the log:
Leaf changes summary: 1 artifact changed
Changed leaf types summary: 0 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 1 Changed, 0 Added function
Removed/Changed/Added variabl
On Sep 12, 2025, at 11:37, Peter Eisentraut wrote:
> I don't think we need any ABI checking until there is a dot-0 release, so I
> don't agree that a facility like that is needed.
Hrm. I wonder how best to filter out a branch without a dot-0 tag.
> Just compare against the previous release tag
On 12.09.25 16:52, David E. Wheeler wrote:
On Sep 12, 2025, at 10:37, Peter Eisentraut wrote:
This was a change that was intentionally backpatched in a different way in
order to preserve ABI compatibility. Compare commits 344662848ac on
REL_18_STABLE and 0b934d3994f on REL_17_STABLE. So ev
On Sep 1, 2025, at 09:12, David E. Wheeler wrote:
>> Also, I think we can also have a configuration option for animal owners to
>> toggle ABI change status on or off, thoughts?
>
> Mabye? Might be worth waiting to see how much of an issue it is. If there is
> a failure a then a fix, it should
On Aug 31, 2025, at 10:17, Mankirat Singh wrote:
> I have updated the module to report a failure status whenever any ABI change
> is detected without specific conditions. For example, the image attached from
> my local server gave a failure status on the ABICompCheck step when comparing
> REL_
On Wed, 27 Aug 2025 at 22:44, David E. Wheeler
wrote:
> > I plan to work on false positives by adding abidiff suppression files
per branch (possibly managed in a community repo). I’d love to hear ideas
on this.
> Also, what rules should be put in place to make a build “fail” based on
what has chan
On Aug 26, 2025, at 17:43, Mankirat Singh wrote:
> If ABI differences are found, you’ll see "log files for step
> abi-compliance-check:"; if not, you’ll see "no abi diffs found in this run"
> (example [3]).
I’m quite happy to have a working build farm animal making these reports.
Yesterday I
Hello Hackers Again!
It's been a long time since we last had a talk and I have a good update on
this project.
If someone is new to this thread so for your context, initially I worked on
checking ABI breakages in PostgreSQL by comparing every two commits on the
stable branches using BuildFarm. But
On Mon, 14 Jul 2025 at 00:32, Tom Lane wrote:
> Another idea could be an in-tree file, different in each branch,
> that records the hash of the commit we presently want to compare to.
> This would require a small amount of additional manual effort to
> maintain, but maybe it's the most flexible wa
"David E. Wheeler" writes:
> How bout we keep it a simple as possible to start with: make it either the
> last tag in the branch or else the first commit in the branch (the branch
> commit). Except for master, in which case perhaps since the last time a
> branch was created?
I do not think we
On Jul 13, 2025, at 15:43, Tom Lane wrote:
> I'm still liking the in-tree-file idea better. For one thing,
> it's not clear how expensive it'd be to search the git metadata
> for this other stuff.
How bout we keep it a simple as possible to start with: make it either the last
tag in the branch
"David E. Wheeler" writes:
> On Jul 13, 2025, at 15:02, Tom Lane wrote:
>> Alternatively, does git have any kind of metadata that isn't
>> a tag but acts sort of like one?
> Notes?
> https://git-scm.com/docs/git-notes
Hmm, maybe. I recall discussion about starting to use notes
to amend commi
On Jul 13, 2025, at 15:02, Tom Lane wrote:
> On reflection, assuming that this is being run by one or more
> buildfarm animals, there are not likely to be so many commits
> between runs that it'll be hard to assign blame after a breakage.
> So I'm not convinced that we need to build the logic you
Mankirat Singh writes:
> 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
On Mon, 14 Jul 2025 at 00:07, David E. Wheeler wrote:
> Presumably you could work your way backwards until the ABI break disappears.
> That should minimize the number of commits you have to compile and test.
Makes sense. Thanks for the suggestion!
Regards,
Mankirat
On Jul 13, 2025, at 14:34, Mankirat Singh wrote:
> 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 perfo
On Sun, 13 Jul 2025 at 05:42, Tom Lane 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 point
"David E. Wheeler" writes:
> For those who didn’t click through, that post has a screenshot of an
> ABI diff report in the build farm server that I think is worth
> seeing:
Nitpick: I think something is backwards about the labeling. AFAICS
the described ABI change was made by 53cd0b71e not its p
Hello Hackers,
I have been working on this project with David since last month.
I've written some blogs about the progress, the most recent one is here [1]
Here's the draft pull request for anyone interested in reviewing the code: [2]
On Wed, 9 Jul 2025 at 17:57, Álvaro Herrera wrote:
> Were you
On Jul 9, 2025, at 11:33, Andres Freund wrote:
> It'd be nice if we could get there, but it'd require annotating *all*
> intentionally exported functions in the backend with PGDLLIMPORT (rather than
> just doing that for variables). Then we could make some symbols
> *intentionally* not exported,
Hi,
On 2025-06-05 19:05:28 +0200, Álvaro Herrera wrote:
> On 2025-Jun-04, Mankirat Singh wrote:
>
> > Here's the workflow I tried to compile
> > $ ./configure CFLAGS="-Og -g -fvisibility=hidden"
> > --prefix=/home/mankirat/install/REL_17_4
> > $ make -j$(nproc)
> >
> > /usr/bin/ld: /home/
Hello Mankirat,
Were you able to make any progress on this?
Thanks,
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Porque francamente, si para saber manejarse a uno mismo hubiera que
rendir examen... ¿Quién es el machito que tendría carnet?" (Mafalda)
On 2025-Jun-04, Mankirat Singh wrote:
> Here's the workflow I tried to compile
> $ ./configure CFLAGS="-Og -g -fvisibility=hidden"
> --prefix=/home/mankirat/install/REL_17_4
> $ make -j$(nproc)
>
> /usr/bin/ld: /home/mankirat/postgres/src/fe_utils/string_utils.c:1154:
> undefined referenc
On Jun 4, 2025, at 12:10, Andres Freund wrote:
> No. It just makes the *name* of the struct visible. The type's definition is
> in the .c file and therefore not visible outside of read_stream.c.
Right, got it, thanks.
David
signature.asc
Description: Message signed with OpenPGP
Hi,
On 2025-06-04 11:15:10 -0400, David E. Wheeler wrote:
> On Jun 4, 2025, at 09:43, Álvaro Herrera wrote:
>
> > You mentioned ReadStream, but that's not exported.
>
> I this not an export at line 67?
>
> ```
> ❯ rg ReadStream src/include/storage/read_stream.h
>
> 50: * the ReadStreamBlockNu
On Wed, 4 Jun 2025 at 19:13, Álvaro Herrera wrote:
> > On Tue, 3 Jun 2025 at 23:50, David E. Wheeler wrote:
> > > What’s the error? Maybe we can fix it.
> >
> > As per my knowledge Postgres internal code lacks visibility annotations on
> > its symbols, which causes compilation errors when fvisibi
On Jun 4, 2025, at 09:43, Álvaro Herrera wrote:
> You mentioned ReadStream, but that's not exported.
I this not an export at line 67?
```
❯ rg ReadStream src/include/storage/read_stream.h
50: * the ReadStreamBlockNumberCB callback to abide by the restrictions of AIO
66:struct ReadStream;
67:ty
On 2025-Jun-04, Mankirat Singh wrote:
> On Tue, 3 Jun 2025 at 23:50, David E. Wheeler wrote:
> > >> Ummm, are you saying that it complains about changes to unexported
> > >> symbols also?
> >
> > This is a good question.
> No, it doesn’t complain about unexported symbols.
You mentioned ReadStrea
On Tue, 3 Jun 2025 at 23:50, David E. Wheeler wrote:
> >> Ummm, are you saying that it complains about changes to unexported
> >> symbols also?
>
> This is a good question.
No, it doesn’t complain about unexported symbols.
But it does complain about some exported symbols that, in my understanding,
On Jun 3, 2025, at 13:23, Mankirat Singh wrote:
>> I don't think it's the
>> job of the tool to determine that this ABI difference is okay.
>> Ultimately that's for a human to determine,
>
> Yes, but it would be better if we could automate that thing to some
> extent, along with the development
On 2025-Jun-03, Mankirat Singh wrote:
> On Tue, 3 Jun 2025 at 20:49, Álvaro Herrera wrote:
> > Please elaborate. Can you not write a suppression file that says
> > "ignore offset changes for ios_in_progress in ReadStream", for example?
>
> I can do that, and that's what's causing the problem.
On Tue, 3 Jun 2025 at 20:49, Álvaro Herrera wrote:
>
> I don't think it's the
> job of the tool to determine that this ABI difference is okay.
> Ultimately that's for a human to determine,
Yes, but it would be better if we could automate that thing to some
extent, along with the development of t
On 2025-Jun-03, Mankirat Singh wrote:
> 'struct ReadStream at read_stream.c:109:1' changed:
> type size hasn't changed
> 1 data member insertion:
> 'int16 io_combine_limit', at offset 2 (in bytes) at read_stream.c:112:1
> there are data member changes:
> 'int16 ios_in_progress' offse
Thanks for the introduction :D
On Tue, 3 Jun 2025 at 00:36, David E. Wheeler wrote:
> Since the work naturally gets into what’s considered a public API and
> what’s not, we feel that hackers is the best place to ask questions about
> bits to include and exclude, as well as other questions relate
Hackers,
I’d like to introduce Mankirat Singh, a Google Summer of Code student that
Pavlo Golub and I are mentoring this year. He’s started work on his project, an
ABI Compliance Checker. The plan is to work out the patterns, integrate it into
the Build Farm, and get it sending regular reports
40 matches
Mail list logo
