meson: Adjust test timeout for Valgrind builds
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t139210psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 01:49 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t139210_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t139210_1 && git checkout t139210_1Patchset v1 (message #1) is on t139210_1
Hi hackers,
When building with -DUSE_VALGRIND, tests run significantly slower due
to Valgrind's instrumentation overhead, causing the default 1000s test's timeout
to be exceeded. Example when running the regress test suite:
"
$ meson test -C build -q --print-errorlogs --setup running --suite regress-running
regress-running - postgresql:regress-running/regress time out (After 1000 seconds)
Summary of Failures:
1/1 regress-running - postgresql:regress-running/regress TIMEOUT 1000.01s
Ok: 0
Fail: 0
Timeout: 1
"
PFA a patch that detects Valgrind builds using a compiler check, which correctly
handles USE_VALGRIND being passed via -Dc_args, CPPFLAGS or CFLAGS and increases
the test timeout to 10000s in that case.
I don't have a strong opinion on the new value. In practice, the regress
suite runs in about 30 seconds without Valgrind and in about 46 minutes with
Valgrind on my setup. Note that the timeout is per test, not for the entire
suite so that 10000s looks large enough (I tested to run the entire suite with
the patch and it did not produce any timeout).
Another option could be to disable the timeout on a Valgrind build (set timeout
to 0) but then a test could block forever.
Note that there are no changes needed for autoconf as it does not set a timeout
for the tests.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On 2026-04-03 14:53:15 +0000, Bertrand Drouvot wrote:
When building with -DUSE_VALGRIND, tests run significantly slower due
to Valgrind's instrumentation overhead, causing the default 1000s test's timeout
to be exceeded. Example when running the regress test suite:"
$ meson test -C build -q --print-errorlogs --setup running --suite regress-running
regress-running - postgresql:regress-running/regress time out (After 1000 seconds)Summary of Failures:
1/1 regress-running - postgresql:regress-running/regress TIMEOUT 1000.01s
Ok: 0
Fail: 0
Timeout: 1
"PFA a patch that detects Valgrind builds using a compiler check, which correctly
handles USE_VALGRIND being passed via -Dc_args, CPPFLAGS or CFLAGS and increases
the test timeout to 10000s in that case.I don't have a strong opinion on the new value. In practice, the regress
suite runs in about 30 seconds without Valgrind and in about 46 minutes with
Valgrind on my setup. Note that the timeout is per test, not for the entire
suite so that 10000s looks large enough (I tested to run the entire suite with
the patch and it did not produce any timeout).Another option could be to disable the timeout on a Valgrind build (set timeout
to 0) but then a test could block forever.Note that there are no changes needed for autoconf as it does not set a timeout
for the tests.
The usual way to deal with that is to pass --timeout-multiplier=100 or
something like that to meson test.
Greetings,
Andres
Hi,
On Mon, Apr 06, 2026 at 09:25:46AM -0400, Andres Freund wrote:
Hi,
On 2026-04-03 14:53:15 +0000, Bertrand Drouvot wrote:
When building with -DUSE_VALGRIND, tests run significantly slower due
to Valgrind's instrumentation overhead, causing the default 1000s test's timeout
to be exceeded. Example when running the regress test suite:"
$ meson test -C build -q --print-errorlogs --setup running --suite regress-running
regress-running - postgresql:regress-running/regress time out (After 1000 seconds)Summary of Failures:
1/1 regress-running - postgresql:regress-running/regress TIMEOUT 1000.01s
Ok: 0
Fail: 0
Timeout: 1
"PFA a patch that detects Valgrind builds using a compiler check, which correctly
handles USE_VALGRIND being passed via -Dc_args, CPPFLAGS or CFLAGS and increases
the test timeout to 10000s in that case.I don't have a strong opinion on the new value. In practice, the regress
suite runs in about 30 seconds without Valgrind and in about 46 minutes with
Valgrind on my setup. Note that the timeout is per test, not for the entire
suite so that 10000s looks large enough (I tested to run the entire suite with
the patch and it did not produce any timeout).Another option could be to disable the timeout on a Valgrind build (set timeout
to 0) but then a test could block forever.Note that there are no changes needed for autoconf as it does not set a timeout
for the tests.The usual way to deal with that is to pass --timeout-multiplier=100 or
something like that to meson test.
Yeah, that's another option but I see it as an extra step if the patched version
still time out. Currently we know for sure that some tests will time out so I
thought that was more use friendly to try to prevent that in the first place and
use the multiplier if it's still not enough for any reasons.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com