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.
