Re: pgsql: Add file_extend_method=posix_fallocate,write_zeros.

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Thomas Munro <tmunro(at)postgresql(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgsql: Add file_extend_method=posix_fallocate,write_zeros.
Date: 2026-02-12 12:02:12
Message-ID: 10e5526f-364c-4867-b6f7-91f13a9494e4@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

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.

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Heikki Linnakangas 2026-02-12 14:21:21 Re: pgsql: Introduce pg_shmem_allocations_numa view
Previous Message Dean Rasheed 2026-02-12 10:00:38 pgsql: Add support for INSERT ... ON CONFLICT DO SELECT.

Browse pgsql-hackers by date

  From Date Subject
Next Message Henson Choi 2026-02-12 12:04:52 Re: Row pattern recognition
Previous Message Ajay Pal 2026-02-12 11:41:25 Re: pg_plan_advice