Thread

  1. meson: Adjust test timeout for Valgrind builds

    Bertrand Drouvot <bertranddrouvot.pg@gmail.com> — 2026-04-03T14:53:15Z

    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
    
  2. Re: meson: Adjust test timeout for Valgrind builds

    Andres Freund <andres@anarazel.de> — 2026-04-06T13:25:46Z

    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
    
    
    
    
  3. Re: meson: Adjust test timeout for Valgrind builds

    Bertrand Drouvot <bertranddrouvot.pg@gmail.com> — 2026-04-07T06:06:17Z

    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