| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Michael Banck <mbanck(at)gmx(dot)net> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Cleaning up historical portability baggage |
| Date: | 2025-06-10 23:09:21 |
| Message-ID: | CA+hUKGLKPMGJCg69qWju_h30CFUPQT+uWvz5rXXR-8v8Uj2_3g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jun 10, 2025 at 10:59 PM Michael Banck <mbanck(at)gmx(dot)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).
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noboru Saito | 2025-06-10 23:39:10 | Re: [PATCH] Proposal: Improvements to PDF stylesheet and table column widths |
| Previous Message | Tom Lane | 2025-06-10 22:56:43 | Re: Cleanup gcc trick with varattrib_1b_e in VARATT_EXTERNAL_GET_POINTER() |