[feature] cherry-pick ABI Check for GitHub Actions

[yihong0618]

Description

Since pg17 also have an ABI issue for the latest release, I think its necessary for cloudberry too.
code in https://github.com/greenplum-db/gpdb-archive/blob/main/.github/workflows/greenplum-abi-tests.yml
its higuoxing's grate job.

and open-gpdb keep and enhance them https://github.com/open-gpdb/gpdb/tree/OPENGPDB_STABLE/.abi-check

@avamingli @edespino

Use case/motivation

No response

Related issues

No response

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

[avamingli]

Hi, @yihong0618

Good idea, thanks.
No objections to this idea in general, and I have a few considerations to keep in mind.

Since pg17 also have an ABI issue for the latest release

I have to say that there is never such a formal promise from Postgres, but Postgres has been doing it very well.
While PostgreSQL maintains a strong commitment to backward compatibility in terms of SQL and user-defined objects, there is no formal guarantee of ABI stability between versions, particularly for C extensions. Developers are advised to test and recompile their extensions when upgrading to new PostgreSQL versions to ensure continued compatibility.

I have no confidence that CBDB could do more and better than Postgres for ABI, if some developers report an issue that our codes breaks their extensions which are not popular well or private ones or not formally supported by CBDB, is it a problem?

For CBDB, as it's iterating fast and more codes will be open source soon.
In most of time, extensions will need re-compile as function signatures will be changed during minor or patch versions.
Then, which level should ABI be checked?

If we have to cherry-pick some bug fixes that break ABI check to a stable branch ex: 1.5.x, what shall we do ?
A SOP(Standard Operating Procedure) is needed if CBDB is going to promise that.

[edespino]

Thank you @yihong0618 and @avamingli for this thoughtful discussion about ABI compatibility checking.

I agree that adopting ABI testing is valuable, but I think we need to frame it within a broader versioning and compatibility strategy. I previously proposed a PostgreSQL-style branching strategy with SemVer (#591) that could help address some of the concerns @avamingli raised:

1. For ABI stability promises:

• Major versions (X.0.0): Can include ABI breaks with clear documentation
• Minor versions (0.X.0): Should maintain ABI compatibility for supported extensions
• Patch versions (0.0.X): Must maintain strict ABI compatibility

This would give us clearer guidelines for:

• When we can make breaking changes
• What level of compatibility testing is needed
• How to handle emergency fixes that might break ABI

The beauty of adopting SemVer is that it provides clear expectations to the community. While PostgreSQL doesn't follow SemVer, we have the opportunity to provide stronger compatibility guarantees that would benefit extension developers.

Regarding the specific concerns about private/unsupported extensions - we could maintain a list of "supported extensions" that are part of our ABI testing suite. This would give us a clear scope for compatibility promises while still allowing the community to build and maintain their own extensions with clear understanding of support levels.

Would it make sense to combine the ABI testing implementation with the versioning proposal? We could start with a small set of core extensions for testing and expand from there.