Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()

From: Mankirat Singh <mankiratsingh1315(at)gmail(dot)com>
To: "David E(dot) Wheeler" <david(at)justatheory(dot)com>, nathandbossart(at)gmail(dot)com, pg(at)bowt(dot)ie, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: andrew(at)dunslane(dot)net, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
Date: 2025-10-18 13:04:17
Message-ID: CAOtk82QCHhWwO=zB-KFYch3JLf8Si4Bk77R_0cgsHjkwuhR9Vg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 18 Oct 2025 at 01:22, David E. Wheeler <david(at)justatheory(dot)com>
wrote:
>
> Adding Mankirat, who developed the ABI checker for his GSoC project.

Thanks!

Really interesting discussion.

On Sat, 18 Oct 2025 at 00:51, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Fri, Oct 17, 2025 at 3:11 PM Nathan Bossart <nathandbossart(at)gmail(dot)com>
wrote:
> > Anything else? I suppose this idea is entirely dependent on the
> > maintainers of the abi-compliance-check code to adapt to it, so we'll
need
> > buy-in from them, too.
>
> That would require parsing the file and understanding that any
> compliance failures associated with a given commit should be
> suppressed. But that seems decidedly nontrivial to me. I can easily
> think of (admittedly somewhat contrived) scenarios where it's
> basically impossible to make this work due to transitive dependencies
> across commits.
>
> I suspect that any practical approach to solving this problem will
> have to involve ignore files that look somewhat like a Valgrind
> suppression file. It'll have to be based on symbol names, plus
> possibly a specific ABI breakage type.

The per-branch file containing the commit hash reference for that branch is
a good solution and can be easily implemented since perl is really good at
working with files.

But if we want a much clearer way based on symbol names, we could use a
standard per branch suppression file, which the abidiff tool directly
supports for this purpose[1].
For example, each branch could have an `abi.suppr` file with content like
this:

# commit hash: 123456abc
[suppress_function]
name=stats_lock_check_privileges
# comments for this function

# commit hash: oldercommit345
[suppress_type]
type_kind = struct
name = some_struct_name
changed_data_members = updated_member_name

If needed, the contents of this file could be truncated on a new minor
release maybe?

Added a patch for the same for handling current abi compliance failures on
baza.

Regards,
Mankirat

[1] -
https://sourceware.org/libabigail/manual/suppression-specifications.html#code-examples

Attachment Content-Type Size
0001-PATCH-Add-ABI-suppressions-file-v1.patch text/x-patch 1.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Srinath Reddy Sadipiralla 2025-10-18 14:17:06 Re: Making pg_rewind faster
Previous Message Tomas Vondra 2025-10-18 11:17:57 Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring