Re: TEMP_CONFIG vs test_aio
Noah Misch <noah@leadboat.com>
From: Noah Misch <noah@leadboat.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, cookt@blackduck.com
Date: 2025-04-01T20:29:11Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
tests: Cope with io_method in TEMP_CONFIG in test_aio
- 327d987df1e7 18.0 landed
-
aio: Add test_aio module
- 93bc3d75d8e1 18.0 cited
On Tue, Apr 01, 2025 at 03:42:44PM -0400, Andres Freund wrote:
> The reason for the failure is simple, the buildfarm animal specifies
> io_method=io_uring (thanks to "cookt" for setting that up so quickly, whoever
> you are :)) and the test is assuming that the -c io_method=... it passes to
> initdb is actually going to be used, but it's overwritten by the TEMP_CONFIG.
> The reason that the test passes -c io_method= to initdb is that I want to
> ensure initdb passes with all the supported io_methods. That still happens
> with TEMP_CONFIG specified, it's just afterwards over-written.
>
> I could just append io_method=$io_method again after $node->init(), but then I
That would be the standard way. Here's the Cluster.pm comment that tries to
articulate the vision:
# If a setting tends to affect whether tests pass or fail, print it after
# TEMP_CONFIG. Otherwise, print it before TEMP_CONFIG, thereby permitting
# overrides. Settings that merely improve performance or ease debugging
# belong before TEMP_CONFIG.
Since anything initdb adds is "before TEMP_CONFIG", we have this outcome.
> couldn't verify that initdb actually ran with the to-be-tested io method.
>
>
> Does anybody have a good suggestion for how to fix this?
>
>
> The least bad idea I can think of is for the test to check if
> PostgreSQL::Test::Utils::slurp_file($ENV{TEMP_CONFIG}) contains the string
> io_method and to append the io_method again to the config if it does. But
> that seems rather ugly.
>
>
> Does anybody have a better idea?
Options:
1. Append, as you mention above
2. Slurp TEMP_CONFIG, as you mention above
3. Slurp postgresql.conf, and fail a test if it doesn't contain io_method.
Then append. If initdb fails to insert io_method, the test will catch it.
4. Run initdb outside of Cluster.pm control, then discard it
My preference order would be roughly 1,3,2,4. The fact that initdb creates a
data directory configured for a particular io_method doesn't prove that initdb
ran with that method, so I don't see 2-4 as testing a lot beyond 1.