Re: GNU/Hurd portability patches
Michael Banck <mbanck@gmx.net>
From: Michael Banck <mbanck@gmx.net>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Thomas Munro <thomas.munro@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>, pgsql-hackers@lists.postgresql.org
Date: 2025-10-12T08:31:28Z
Lists: 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add minimal sleep to stats isolation test functions.
- ef18eeeeaea7 18.1 landed
- e849bd551c32 19 (unreleased) landed
- fa42213d4af6 15.15 landed
- b4ef835f5e7d 17.7 landed
- 21ada43a6105 16.11 landed
-
Include pg_test_timing's full output in the TAP test log.
- 7ccbf6d8b5e5 19 (unreleased) landed
-
Make sure IOV_MAX is defined.
- d25d392e8944 16.10 landed
- 581305a4659d 18.0 landed
- 1fd772d19290 19 (unreleased) landed
- 0991249d7ab5 17.6 landed
-
Make safeguard against incorrect flags for fsync more portable.
- d0a695cf41de 13.22 landed
- 71d71ac4d1bb 14.19 landed
- 0fb496c704fc 15.14 landed
- 45c5276628d1 18.0 landed
- 3a2617e4f0be 16.10 landed
- 29c54ea7b49c 17.6 landed
- 29213636e6cd 19 (unreleased) landed