Horton
Menu

Re: GNU/Hurd portability patches

Michael Banck <mbanck@gmx.net>

View thread
From: Michael Banck <mbanck@gmx.net>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org, Thomas Munro <thomas.munro@gmail.com>
Date: 2025-09-21T11:02:27Z
Lists: pgsql-hackers 
Hi,

On Sun, Sep 21, 2025 at 09:00:00AM +0300, Alexander Lakhin wrote:
> 02.07.2025 02:53, Michael Paquier wrote:
> > Catching up on this thread after-the-fact, specifically looking at
> > 29213636e6cd as I did the original check tweaked here for O_RDONLY.
> > Agreed that a backpatch should be OK as done.  The buildfarm looks OK
> > currently.
> 
> Three months later we can see a number of failures produced by that
> animal on several branches, e.g. [1]:
> timed out after 3600 secs

Right, I've noticed them as well of course, but did not have time to
take a closer look yet. This timeout in test_shm_mq happens on 32bit
hurd-i386 as well, btw.

> It's not that easy to see a backtrace of the running processes on that OS,
> but with some debug logging (attached), I can see that the test backend
> process or shm_mq background worker just gets stuck shortly after poll().

Thanks for taking a deeper look.

> So it seems to me that Hurd is not mature enough yet to test Postgres.

That is a bit harsh; this issue should be looked into, but I would not
say it is not mature enough to test Postgres.


Michael

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add minimal sleep to stats isolation test functions.

  2. Include pg_test_timing's full output in the TAP test log.

  3. Make sure IOV_MAX is defined.

  4. Make safeguard against incorrect flags for fsync more portable.