Re: Cleaning up historical portability baggage - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Cleaning up historical portability baggage
Date
Msg-id CA+hUKGLKPMGJCg69qWju_h30CFUPQT+uWvz5rXXR-8v8Uj2_3g@mail.gmail.com
Whole thread Raw
In response to Re: Cleaning up historical portability baggage  (Michael Banck <mbanck@gmx.net>)
List pgsql-hackers
On Tue, Jun 10, 2025 at 10:59 PM Michael Banck <mbanck@gmx.net> wrote:
> I don't have an opinion here, I think it would be ok to just define it
> to 16 if it is undefined and if the Hurd people want something better at
> some point, they should submit patches.

Cool.  I will go ahead and do that, as you proposed, and back-patch
appropriately.  This will have zero effect on any other system, and is
justifiable as a bug fix based on the POSIX spec.

Hurd builds will be slightly stunted in the sense that they won't be
able to set io_combine_limit > 128kB.  Fixing that will be a matter
for another day (I'm not sure if it's worth bothering with
sysconf(_SC_IOV_MAX), I guess they probably just return -1 anyway
(meaning unlimited), which means that we'd apply our own cap of 128,
so maybe it's easier to just skip the middle step and somehow just use
128 already... but yeah, patches welcome for v19).



pgsql-hackers by date:

Previous
From: "Daniel Verite"
Date:
Subject: Re: CREATE DATABASE command for non-libc providers
Next
From: Noboru Saito
Date:
Subject: Re: [PATCH] Proposal: Improvements to PDF stylesheet and table column widths