Обсуждение: Re: pgsql: Add file_extend_method=posix_fallocate,write_zeros.

On 06.02.26 12:30, Michael Paquier wrote:
> Hi Thomas,
> 
> On Fri, Feb 06, 2026 at 05:09:54AM +0000, Thomas Munro wrote:
>> Add file_extend_method=posix_fallocate,write_zeros.
> 
> It looks like you need to update .abi-compliance-check for stable
> branches down to v16, due to the new entry added to
> ConfigureNamesEnum.  See:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2026-02-06%2009%3A27%3A27

I suppose technically this is an ABI change since the size of 
ConfigureNamesEnum is changed, but it seems this is irrelevant in 
practice.  Could it be possible to ignore stuff like this without manual 
intervention?

The concern is that say authors or packagers of extensions will observe 
that there was an ABI change and will think they have to do some extra 
work, but in practice probably not.

The goal should be to not have ABI changes in stable branches.  If we 
just keep marking ABI changes without distinction, then this could lead 
to fatigue.

Peter Eisentraut <peter@eisentraut.org> writes:
> I suppose technically this is an ABI change since the size of 
> ConfigureNamesEnum is changed, but it seems this is irrelevant in 
> practice.  Could it be possible to ignore stuff like this without manual 
> intervention?

I am working on a bug report to libabigail, arguing that this should
not be reported as an ABI diff (at least not in --headersdir mode).
That's at best a long-term solution, but on the other hand it's
not every day that we add a new GUC to back branches.

There was upthread discussion about using a suppression file, but
that'd require some testing to ensure that it does what we want
and nothing more nor less.  (For instance, if suppressing
ConfigureNamesEnum resulted in no complaints about changes in
struct config_enum, that'd be very bad.)

Keep in mind also that libabigail seems to have some nasty blind
spots.  (I'm about to post something to pgsql-hackers about one that
I found last week.)

For the time being, I think we'd be well advised to treat the abidiff
reports as an experimental work-in-progress.  They might eventually
get to the level of trustworthiness that you seem to be envisioning,
but we're not there yet.

            regards, tom lane

I wrote:
> Peter Eisentraut <peter@eisentraut.org> writes:
>> I suppose technically this is an ABI change since the size of 
>> ConfigureNamesEnum is changed, but it seems this is irrelevant in 
>> practice.  Could it be possible to ignore stuff like this without manual 
>> intervention?

> I am working on a bug report to libabigail, arguing that this should
> not be reported as an ABI diff (at least not in --headersdir mode).

So I tried to make a small reproducer, and failed.  Then I ran the
buildfarm script (with abidiff enabled) against c6881f79228,
right before the last .abi-compliance-history update, and it passed.
IOW, the version of abidiff I have here does not seem to have this
bug.  It's 2.8.0 from last July or so.

Now I'm wondering exactly what libabigail releases crake and baza
are using.

            regards, tom lane

On Feb 12, 2026, at 14:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Now I'm wondering exactly what libabigail releases crake and baza
> are using.

Baza has 2.2.0, installed from Bookworm packaging. I can see about upgrading it this weekend, either building from
sourceor making a new VM with Trixie. 

D