From: Michael Banck <mbanck@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Safeguards against incorrect fd flags for fsync()
Date: Tue, 24 Jun 2025 07:51:08 +0200
Message-ID: <685a3ccd.170a0220.2d27e6.2232@mx.google.com> (raw)
In-Reply-To: <6849d7e8.5d0a0220.3dbe66.c4e1@mx.google.com>
References: <20191009062640.GB21379@paquier.xyz>
<68480868.5d0a0220.1e214d.68a6@mx.google.com>
<aEjGRrGNoLewSlRG@paquier.xyz>
<947174.1749604175@sss.pgh.pa.us>
<6849d7e8.5d0a0220.3dbe66.c4e1@mx.google.com>
Hi,
another update:
On Wed, Jun 11, 2025 at 09:24:24PM +0200, Michael Banck wrote:
> So it seems the low-resolution timer is the only functional issue right
> now. I upgraded my VM to current Debian unstable, but unfortunately that
> did not increase the timer resolution is hoped, maybe some more pieces
> in glibc are missing, I checked in on that[1]. In any case, they are
> actively working on this.
I got it working, I had to rebuild gnumach with --enable-apic in order
to get HPET. With that, the regular build-farm checks (check/
installcheck in contrib, src/test/regress and src/test/isolation) pass
without patches to testsuite timings.
> However, there is another caveat:
>
> Running "make check" manually only sometimes hangs the VM (without any
> output anywhere), while running it via the buildfarm client reliably
> makes it hang each time, so I added --tests=test_setup as a work-around
> to test the other stages. I have not found a reason for this yet, I will
> try to get a serial console working for the VM next, maybe that will
> show some helpful info.
This was due to the build-farm running on HEAD with a config including
debug_parallel_query=on, which adds a lot of strain on the machine I
guess? As this is a single-node VM, I guess it overloaded it regularly.
I reported that and I think this is something that needs to be
addressed, but people are working on similar issues right now[1].
Is removing the debug_parallel_query=on configuration for HEAD a valid
mode of operation for a buildfarm animal? I ran the tests 10 times in a
row without issues today.
Michael
[1] https://lists.debian.org/debian-hurd/2025/05/msg00031.htmlhttps://lists.debian.org/debian-hurd/2025/05/msg00031.html
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: mbanck@gmx.net, tgl@sss.pgh.pa.us, michael@paquier.xyz, pgsql-hackers@lists.postgresql.org
Subject: Re: Safeguards against incorrect fd flags for fsync()
In-Reply-To: <685a3ccd.170a0220.2d27e6.2232@mx.google.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox