Re: GNU/Hurd portability patches - Mailing list pgsql-hackers

From Michael Banck
Subject Re: GNU/Hurd portability patches
Date
Msg-id 68eb6761.7b0a0220.1711d0.1819@mx.google.com
Whole thread Raw
In response to Re: GNU/Hurd portability patches  (Alexander Lakhin <exclusion@gmail.com>)
Responses Re: GNU/Hurd portability patches
List pgsql-hackers
Hi Alexander,

On Sat, Oct 11, 2025 at 03:00:00PM +0300, Alexander Lakhin wrote:
> Thank you for your attention to that anomaly!

Sorry, I missed Thomas' initial mail on this somewow.

> Whilst from a failed run, I got:

Any way to easily reproduce this? It happened only once on fruitcrow so
far.

I wonder whether this is a problem in the (relatively new) x86-64 port,
so I'd like to try to reproduce it on i386.

> > I've so far resisted the urge to spin up a Debian GNU/Hurd box to
> > figure any of that out for myself, but maybe someone has a clue...
> 
> That's pretty wise — the most frustrating thing with Hurd VM, which I
> created as described above, is that it hangs during tests (only 1 out of
> 5 `make check` runs completes) and killing the hanging processes doesn't
> restore it's working state — I have to reboot it (and fsck finds FS errors
> on each reboot) or even restore a copy of VM's disk.

I had to reboot fruitcrow last night because it had crashed, but that
was the first time in literally weeks. I tend to reboot it once a week,
but otherwise it ran pretty stable.

It took me a while to get there though before I applied for it to be a
buildfarm animal, here is what I did:

1) (builfarm client specific): removed "HEAD => ['debug_parallel_query =
regress']," and set "MAX_CONNECTIONS => '3'," in build-farm.conf, to
reduce concurrency.

2. Gave it 4G of memory to the VM via KVM. Also set -M q35, but I guess
you are already doing that as it does not boot properly otherwise IME.

3. Removed swap (this is already the case for the x86-64 2025 Debian
image, but it was not the case for the earlier 2023 i386 image when I
started this project). Paging to disk has been problematic and prone to
issues (critical parts getting paged out accidently), but this has been
fixed over the summer so in principle running a current gnumach/hurd
package combination from unstable should be fine again.

4. Removed tmpfs translators (so that the default-pager is not used
anywhere, in conjunction with not setting swap, see above), by setting 
RAMLOCK=no and RAMTMP=no in /etc/default/tmpfs, as well as commenting
out 'mount_run mount_noupdate'/'mount_tmp mount_noupdate' in
/etc/init.d/mountall.sh and 'mount_run "$MNTMODE"' in
/etc/init.d/mountkernfs.sh (maybe there is a more minimal change, but
that is what I have right now).

5. Set the sync interval for the root file system to 5s in /etc/fstab
(this will not help with crashes, but likely make file system corruption
less bad, so recovering from them will be easier):
/dev/wd0s2      /               ext2    sync=5          0       1


Hope that helps,

Michael



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: another autovacuum scheduling thread
Next
From: Álvaro Herrera
Date:
Subject: Re: remove unnecessary include in src/backend/commands/policy.c