From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter@eisentraut.org>
cc: Michael Paquier <michael@paquier.xyz>,
        Thomas Munro <tmunro@postgresql.org>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: pgsql: Add file_extend_method=posix_fallocate,write_zeros.
In-reply-to: <10e5526f-364c-4867-b6f7-91f13a9494e4@eisentraut.org>
References: <E1voE6M-001P1f-18@gemulon.postgresql.org>
 <aYXQ3VhPEqkTi0dZ@paquier.xyz>
 <10e5526f-364c-4867-b6f7-91f13a9494e4@eisentraut.org>
Comments: In-reply-to Peter Eisentraut <peter@eisentraut.org>
	message dated "Thu, 12 Feb 2026 13:02:12 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <286103.1770911626.1@sss.pgh.pa.us>
Date: Thu, 12 Feb 2026 10:53:46 -0500
Message-ID: <286104.1770911626@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/286104.1770911626%40sss.pgh.pa.us>
Precedence: bulk

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