public inbox for [email protected]
help / color / mirror / Atom feedFrom: Noah Misch <[email protected]>
To: Andres Freund <[email protected]>
Cc: [email protected]
Cc: [email protected]
Subject: Re: TEMP_CONFIG vs test_aio
Date: Tue, 1 Apr 2025 13:29:11 -0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <zh5u22wbpcyfw2ddl3lsvmsxf4yvsrvgxqwwmfjddc4c2khsgp@gfysyjsaelr5>
References: <[email protected]>
<zh5u22wbpcyfw2ddl3lsvmsxf4yvsrvgxqwwmfjddc4c2khsgp@gfysyjsaelr5>
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.
view thread (8+ messages) latest in thread
reply
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: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: TEMP_CONFIG vs test_aio
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox