Horton
Menu

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Remove gen_node_support.pl's ad-hoc ABI stability check.

  2. Add defenses against unexpected changes in the NodeTag enum list.

  1. Do we still need gen_node_support.pl's nodetag ABI stability check?

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-04-14T05:04:33Z

    We're still a couple months away from cutting the REL_19_STABLE
branch, but I was contemplating that just now, and it occurred to me
to wonder whether we still need gen_node_support.pl's single-purpose
ABI check (cf commit eea9fa9b2) now that we have buildfarm animals
running general-purpose ABI stability checks.

On the one hand, there's much to be said for belt-and-suspenders-too
safety checks.  On the other hand, updating gen_node_support.pl is
an extra manual step while creating a branch, so it's easy to forget
or get wrong.  It's also not very clear why this particular sort
of ABI break in a stable branch is any worse than other hazards.

I'm not really set either way, but my first thought is to drop
the special mechanism.

			regards, tom lane

  2. Re: Do we still need gen_node_support.pl's nodetag ABI stability check?

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-04-15T18:13:46Z

    I wrote:
> We're still a couple months away from cutting the REL_19_STABLE
> branch, but I was contemplating that just now, and it occurred to me
> to wonder whether we still need gen_node_support.pl's single-purpose
> ABI check (cf commit eea9fa9b2) now that we have buildfarm animals
> running general-purpose ABI stability checks.

> On the one hand, there's much to be said for belt-and-suspenders-too
> safety checks.  On the other hand, updating gen_node_support.pl is
> an extra manual step while creating a branch, so it's easy to forget
> or get wrong.  It's also not very clear why this particular sort
> of ABI break in a stable branch is any worse than other hazards.

> I'm not really set either way, but my first thought is to drop
> the special mechanism.

Hearing no objections, I went ahead and wrote a patch for that.
Doing that reminded me that it's a really incomplete check anyway,
as it only verifies that the last auto-assigned NodeTag number
hasn't changed.  Re-ordering earlier entries, for example, would
not get detected.  So even on its own terms it's little more than
a stopgap; the buildfarm's libabigail checks are far more thorough.

Barring objections, I'll push this soon.

			regards, tom lane

  3. Re: Do we still need gen_node_support.pl's nodetag ABI stability check?

    Daniel Gustafsson <daniel@yesql.se> — 2026-04-15T18:45:07Z

    > On 15 Apr 2026, at 20:13, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Barring objections, I'll push this soon.

+1, the new checks are far more comprehensive.  Looks good from a readthrough
and grepping the codebase doesn't turn up any other mentions.

--
Daniel Gustafsson

  4. Re: Do we still need gen_node_support.pl's nodetag ABI stability check?

    Peter Eisentraut <peter@eisentraut.org> — 2026-04-15T19:30:17Z

    On 14.04.26 07:04, Tom Lane wrote:
> On the one hand, there's much to be said for belt-and-suspenders-too
> safety checks.  On the other hand, updating gen_node_support.pl is
> an extra manual step while creating a branch, so it's easy to forget
> or get wrong.  It's also not very clear why this particular sort
> of ABI break in a stable branch is any worse than other hazards.

This might still be helpful because it checks during local builds and 
doesn't rely on the buildfarm.

  5. Re: Do we still need gen_node_support.pl's nodetag ABI stability check?

    Daniel Gustafsson <daniel@yesql.se> — 2026-04-15T19:47:05Z

    > On 15 Apr 2026, at 21:30, Peter Eisentraut <peter@eisentraut.org> wrote:
> 
> On 14.04.26 07:04, Tom Lane wrote:
>> On the one hand, there's much to be said for belt-and-suspenders-too
>> safety checks.  On the other hand, updating gen_node_support.pl is
>> an extra manual step while creating a branch, so it's easy to forget
>> or get wrong.  It's also not very clear why this particular sort
>> of ABI break in a stable branch is any worse than other hazards.
> 
> This might still be helpful because it checks during local builds and doesn't rely on the buildfarm.

But does it actually give a good enough answer to be relied upon when passing
the local check can fail the buildfarm check?

--
Daniel Gustafsson

  6. Re: Do we still need gen_node_support.pl's nodetag ABI stability check?

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-04-16T01:46:46Z

    Daniel Gustafsson <daniel@yesql.se> writes:
> On 15 Apr 2026, at 21:30, Peter Eisentraut <peter@eisentraut.org> wrote:
>> This might still be helpful because it checks during local builds and doesn't rely on the buildfarm.

> But does it actually give a good enough answer to be relied upon when passing
> the local check can fail the buildfarm check?

Yeah, my answer to that is still "why is this particular case more
important than any other ABI breakage you might cause while hacking
on a back branch?".  I quite agree that being able to check for ABI
breakage locally can be useful.  But what we ought to do is make it
easier for people to use libabigail for that without spinning up a
local buildfarm instance.  Perhaps we could extract the buildfarm's
ABICompCheck.pm script into some standalone tool.

			regards, tom lane

  7. Re: Do we still need gen_node_support.pl's nodetag ABI stability check?

    Daniel Gustafsson <daniel@yesql.se> — 2026-04-16T14:33:23Z

    > On 16 Apr 2026, at 03:46, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> Daniel Gustafsson <daniel@yesql.se> writes:
>> On 15 Apr 2026, at 21:30, Peter Eisentraut <peter@eisentraut.org> wrote:
>>> This might still be helpful because it checks during local builds and doesn't rely on the buildfarm.
> 
>> But does it actually give a good enough answer to be relied upon when passing
>> the local check can fail the buildfarm check?
> 
> Yeah, my answer to that is still "why is this particular case more
> important than any other ABI breakage you might cause while hacking
> on a back branch?".  I quite agree that being able to check for ABI
> breakage locally can be useful.  

Agreed.

> But what we ought to do is make it
> easier for people to use libabigail for that without spinning up a
> local buildfarm instance.  Perhaps we could extract the buildfarm's
> ABICompCheck.pm script into some standalone tool.

While I have zero insights into how complicated that would be, off the cuff it
seems like the right approach.

--
Daniel Gustafsson