From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Handle TEMP_CONFIG for pg_regress style tests in pg_regress.c |
Date: | 2023-02-18 20:26:11 |
Message-ID: | 20230218202611.cp7ke2tz5lnafu5z@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
When building with meson, TEMP_CONFIG is supported for TAP tests, but doesn't
do anything for regress/isolation.
The reason for that is that meson's (and ninja's) architecture is to separate
"build setup" from the "build/test/whatever" stage, moving dynamism (and more
costly operations) to the "setup" phase.
In this case the implication is that the command line for the test isn't
re-computed dynamically. But pg_regress doesn't look at TEMP_CONFIG, it just
has a --temp-config=... parameter, that src/Makefile.global.in dynamically
adds if TEMP_CONFIG is set.
In contrast to that, TEMP_CONFIG support for tap tests is implemented in
Cluster.pm, and thus works transparently.
My inclination is to move TEMP_CONFIG support from the Makefile to
pg_regress.c. That way it's consistent across the build tools and isn't
duplicated. pg_regress already looks at a bunch of temporary variables
(e.g. PG_REGRESS_SOCK_DIR, PG_TEST_USE_UNIX_SOCKETS), so this isn't really
breaking new ground.
It can be implemented differently, e.g. by adding the parameter dynamically in
the wrapper around pg_regress, but I don't see an advantage in that.
Patch attached.
Greetings,
Andres Freund
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Move-TEMP_CONFIG-into-pg_regress.c.patch | text/x-diff | 5.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2023-02-18 20:42:21 | Re: Reducing connection overhead in pg_upgrade compat check phase |
Previous Message | Andres Freund | 2023-02-18 20:09:00 | Re: windows CI failing PMSignalState->PMChildFlags[slot] == PM_CHILD_ASSIGNED |