Hi, On Tue, Jun 10, 2025 at 09:05:03AM +1200, Thomas Munro wrote: > On Tue, Jun 10, 2025 at 2:25 AM Andres Freund <and...@anarazel.de> wrote: > > On 2025-06-09 15:25:22 +0200, Michael Banck wrote: > > > Postgres built fine up and until v15 on the Hurd, so this is a build > > > regression, and the fact that we define #PG_IOV_MAX to at most 32 > > > anyway suggest we could just #definde IOV_MAX to 16 if undefined as on > > > Windows. > > > > I think our policy basically is that if it doesn't exist on the BF, it's > > unsupported. Also note that Hurd is not listed as a supported OS: > > https://www.postgresql.org/docs/devel/supported-platforms.html > > > > We can't design for OS that we don't know it's used with postgres and/or how > > that OS works / what it supports. > > > > So I reject the premise that this is a regression. > > > > If you want to argue that we should add support for Hurd, you can do that, > > but > > that's obviously a different discussion. > > Since time immemorial, PostgreSQL could compile successfully on > GNU/Hurd systems (perhaps with a few superficial tweak patches of this > ilk), but it couldn't actually run because its semaphores didn't work > cross-process. I knew that because Christoph told us somewhere on > this list not so long ago, but it seems there has been some movement > since then and I am guilty of being wrong on the internet, as > mentioned here: > > https://savannah.gnu.org/task/?7050
Yeah. > So it looks like they added working semaphores in 2022, but in 2023 I > removed some unrelated stuff during and happened to mention that Hurd > can't run PostgreSQL anyway, and they didn't like that (I mean it > wasn't an unreasonable chain of thought, it was just unfortunate > timing given they'd worked on addressing that). The log linked there > shows the regression tests mostly passing, so that seems promising: at > least a cluster can finally actually start up and run! There may be a > few more little things to chase down, who knows. I tried again (as seen in this thread) and the current status is: 1. build failure due to IOV_MAX being undefined (under discussion here) 2. initdb (at least) fails with assert-enabled builds due to O_RDONLY being 1 on the Hurd and 0 everywhere else, I sent a patch for that here: https://www.postgresql.org/message-id/68480868.5d0a0220.1e214d.68a6%40mx.google.com 3. make check nowadays succeeds the subscription test that it failed in the log mentioned in the above task, but it still fails the stats test: |@@ -672,7 +672,7 @@ | SELECT stats_reset > :'slru_commit_ts_reset_ts'::timestamptz FROM pg_stat_slru WHERE name = 'CommitTs'; | ?column? | ---------- |- t |+ f | (1 row) | | SELECT stats_reset > :'slru_notify_reset_ts'::timestamptz FROM pg_stat_slru WHERE name = 'Notify'; |@@ -769,7 +769,7 @@ | SELECT stats_reset > :'db_reset_ts'::timestamptz FROM pg_stat_database WHERE datname = (SELECT current_database()); | ?column? | ---------- |- t |+ f | (1 row) | | ---- I'll try to figure out why that is next. > I wonder if the pthreads implementation is still unfinished as hinted > at there too. I think it is reasonably complete nowadays that I don't think it makes sense to worry about this right now. > Anyway, that's a long way of saying +1, GNU/Hurd would be a new > platform for us, and obviously it hasn't even been plausible until > quite recently. There are also circularities when you're bringing up > an OS and application support for it in parallel, so there will no > doubt be a few little threads like this along the way, and I'm not > against helping on our side. More than that, for the specific point, > yeah the GNU project's unlimited limits thing is kinda admirable, and > they are quite right to complain about this one: {IOV_MAX} appears > with curly braces in POSIX and <limits.h> says: > > "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 irrespective of Hurd support, it was a mistake to require the > symbol to be defined, based on POSIX language lawyering alone. It's > annoying though, we've hit the only known system so far that doesn't > actually define it, and POSIX then says we can only rely on 16 if we > want a compile-time limit. Yet Hurd presumably really wants to make > it unlimited (well limited only by things like data types), while > POSIX says that if we want to use anything but the required minimum > when the macro isn't defined, we should call sysconf(_SC_IOV_MAX) at > runtime. So... I guess the correct thing to do may be to use 16 for > the benefit of our (few) statically sized arrays that Richard Stallman > would hate, but also consult sysconf() when limiting > io_max_combine_limit, our own runtime bound on I/O combining for the > main serious user of vectored I/O. A little complicated, but... > they're quite right about all that. Hnghh. 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. Michael
