| 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.
| 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. |
| 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 |