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
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] --- comm
On Wed, 1 Nov 2023 at 16:43, Peter Eisentraut wrote:
>
> Here is an updated version of this patch. It doesn't have any new
> functionality, just a rebase and some minor adjustments.
>
> I have split up the one patch into several ones, which could be
> considered incrementally, namely:
>
> v3-0001
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. I was not fam
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 details about how things changed
On Sun, May 28, 2023 at 8:37 AM Tom Lane wrote:
> I gather it'd catch things like NodeTag enum assignments changing,
> which is something we really need to have a check for.
Right. Any ABI break that involves machine-generated translation units
seems particularly prone to being overlooked. Just e
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 what the
> tool had to s
35 matches
Mail list logo
