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,
me
> extent, along with the development of the ABI compliance checker.
To which thing do you refer here? If I understand Álvaro correctly, it might be
best to start out excluding no symbols at all, and leaving it to humans to
decide whether there is an issue or not.
> 'struct ResultR
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.
ong with the development of the ABI compliance checker.
> and they must either add an
> suppression to the Postgres source code somehow, or modify or revert the
> commit so that the ABI change disappears.
That's exactly what I aim for with this project, by just automatically
run
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
Greetings old thread.
On Mar 4, 2024, at 07:50, Peter Eisentraut wrote:
> Maybe the way forward here is to write a buildfarm module for this, and then
> see from there what further needs there are.
Given the PostgreSQL 17.1 kerfuffle and the addition of API and API guidance to
the docs (discu
On Mon, Mar 4, 2024 at 7:50 AM Peter Eisentraut wrote:
> Looking at this again, if we don't want the .xml files in the tree, then
> we don't really need this patch series.
Based on this, I've updated the status of this patch in the CommitFest
application to Withdrawn. If that's not correct, pleas
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 y
On 2024-Feb-27, Peter Geoghegan wrote:
> I have a feeling that there are going to be real problems with
> alerting, at least if it's introduced right away. I'd feel much better
> about it if there was an existing body of suppressions, that more or
> less worked as a reference of agreed upon best p
On Tue, Feb 27, 2024 at 9:03 AM Alvaro Herrera wrote:
> Now, maybe a buildfarm animal is not the right tool, and instead we need
> a separate system that tests for it and emails pg-hackers when it breaks
> or whatever. That's fine with me, but it seems a pretty minor
> implementation detail.
Anyt
On 2024-Feb-27, Peter Geoghegan wrote:
> On Tue, Feb 27, 2024 at 8:25 AM Alvaro Herrera
> wrote:
> > 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
On Tue, Feb 27, 2024 at 8:25 AM Alvaro Herrera wrote:
> 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 cha
On 2023-Nov-01, Peter Eisentraut wrote:
> v3-0001-abidw-option.patch
>
> This adds the abidw meson option, which produces the xml files with the ABI
> description. With that, you can then implement a variety of workflows, such
> as the abidiff proposed in the later patches, or something rigged u
On 06.01.24 18:25, vignesh C wrote:
One of the test has failed in cfbot at [1] with:
abi-compliance-checker
[12:04:10.537] The output from the failed tests:
[12:04:10.537]
[12:04:10.537] 129/282 postgresql:abidiff / plpgsql.abidiff FAIL 1.25s
(exit status 4)
[12:04:10.537]
[12:04:10.537
eate, etc., so I'm not hung up on this right now,
> it's mostly a demonstration.
>
> v3-0004-abidiff-support-files.patch
>
> This contains the support files for patch 0003, just split out because
> they are bulky and boring.
One of the test has failed in cfbot at [1]
On 10.06.23 22:24, Andres Freund wrote:
Looks like we ought to add --exported-interfaces-only?
Btw., this option requires libabigail 2.1, which isn't available
everywhere yet. For example, Debian oldstable (used on Cirrus) doesn't
have it yet. So I'll leave this patch set as is for now. If
On Mon Jun 12, 2023 at 10:10 AM CDT, Tristan Partin wrote:
> On Sat Jun 10, 2023 at 9:17 AM CDT, Peter Eisentraut wrote:
> > I have rearranged this a bit. There are now two build options, called
> > abidw and abidiff. The abidw option produces the xml file, that you
> > would then at appropriat
On Sat Jun 10, 2023 at 9:17 AM CDT, Peter Eisentraut wrote:
> I have rearranged this a bit. There are now two build options, called
> abidw and abidiff. The abidw option produces the xml file, that you
> would then at appropriate times commit into the tree as the base. The
> abidiff option en
Andres Freund writes:
> Independently, I'm a bit confused as to why we export pgresStatus in
> exports.txt - I don't see any reason for that. Looks like it might be leftover
> from before fa0f24165c0?
It looks like before fa0f24165, the *only* way to convert ExecStatusType
to text was to access t
Hi,
On 2023-06-10 12:48:46 -0700, Andres Freund wrote:
> > +
> > +
> > +
>
> Hm - why is all of this stuff even ending up in the external ABI? It should
> all be internal, unless I am missing something?
>
> I might be looking the wrong way, but to me it sure looks like none of that
Hi,
On 2023-06-06 18:30:38 +0200, Peter Eisentraut wrote:
> On 30.05.23 06:32, Peter Eisentraut wrote:
> > I think the way to use this would be to compute the ABI for the .0
> > release (or rc1 or something like that) and commit it into the tree. And
> > then compute the current ABI and compare th
+abidiff = find_program('abidiff', native: false, required: false)
+abidw = find_program('abidw', native: false, required: false)
+
+abidw_flags = [
+ '--drop-undefined-syms',
+ '--no-architecture',
+ '--no-comp-dir-path',
+ '--no-elf-needed',
+ '--no-show-locs',
+ '--type-id-style', 'hash',
On 27.05.23 02:52, Peter Geoghegan wrote:
Attached is a html report that was generated by a tool called
abi-compliance-checker/abi-dumper [1][2] (by using
"abi-compliance-checker -l libTest ... ") .
I have been using the libabigail library/set of tools (abidiff, abidw)
for this.
On Sun, May 28, 2023 at 9:34 AM Peter Geoghegan wrote:
> I'll try to come up with a standard abi-compliance-checker Postgres
> workflow once I'm back from pgCon.
Ideally, we'd be able to produce reports that cover an entire stable
release branch at once, including det
ooked. Just eyeballing code
(and perhaps double-checking struct layout using pahole) seems
inadequate.
I'll try to come up with a standard abi-compliance-checker Postgres
workflow once I'm back from pgCon. It already looks like
abi-compliance-checker is capable of taking most of the
I wrote:
> (Which reminds me that I forgot to turn on the ad-hoc check for
> that in gen_node_support.pl. I'll go do that, but it'd be better
> to have a more general-purpose solution.)
Oh, scratch that, it's not supposed to happen until we make the
v16 branch. It'd still be better to not need i
Peter Geoghegan writes:
> I tried comparing REL_11_0 to REL_11_20. Attached is the report for that.
Nice!
> I don't have time to study this in detail today, but the report seems
> to have a plausible variety of issues. I noticed that it warns about
> the breaking signature change to _bt_pagedel(
Peter Geoghegan writes:
> Attached is a html report that was generated by a tool called
> abi-compliance-checker/abi-dumper [1][2] (by using
> "abi-compliance-checker -l libTest ... ") . I deliberately introduced
> 2 ABI compatibility issues affecting postgres, just to see
Attached is a html report that was generated by a tool called
abi-compliance-checker/abi-dumper [1][2] (by using
"abi-compliance-checker -l libTest ... ") . I deliberately introduced
2 ABI compatibility issues affecting postgres, just to see what the
tool had to say about it.
The first
51 matches
Mail list logo
