Re: GNU/Hurd portability patches

From: Michael Banck <mbanck(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Re: GNU/Hurd portability patches
Date: 2025-07-01 20:01:37
Message-ID: 68643ea2.050a0220.128f53.3f77@mx.google.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Tue, Jul 01, 2025 at 12:41:50PM -0400, Tom Lane wrote:
> Michael Banck <mbanck(at)gmx(dot)net> writes:
> > please find attached the current patches required to get master built
> > and the testsuites run on Debian's hurd-i386 port. I have not had the
> > time to test the hurd-amd64 port in the same fashion, but will do so
> > next.
>
> Pushed, after some fooling with the comments and commit messages.

Thanks! Also for back-patching them.

Regarding the comment,

| * If <limits.h> didn't define IOV_MAX, define our own. X/Open requires at
| * least 16. (GNU Hurd apparently feel that they're not bound by X/Open,
| * because they don't define this symbol at all.)

I personally don't care much about those missing limits on the Hurd, but
Thomas mentioned in
CA+hUKG+tqFVY7Fi=WBvZ6-UsATjcPNBDtphDm7YLjevm2kxSvw(at)mail(dot)gmail(dot)com (and
Samuel Thibault cited the same sentence to me now when I discussed the
commit with him) that POSIX said "A definition of one of the symbolic
constants in the following list shall be omitted from <limits.h> on
specific implementations where the corresponding value is equal to or
greater than the stated minimum, but is unspecified". So "requires at
least 16" might be a bit too strong here, AIUI.

> Please go ahead and set up a Hurd buildfarm member, so that it
> stays fixed.

Right, will look into this next.

Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2025-07-01 20:06:04 Re: teach pg_upgrade to handle in-place tablespaces
Previous Message Nathan Bossart 2025-07-01 19:20:40 Re: [PATCH] Use binaryheap_* macro where appropriate