Hello Andrew,
28.07.2024 22:43, Andrew Dunstan wrote:
>
> Maybe, IDK. Meanwhile, I disabled "debug_parallel_query = regress" on HEAD for fairywren and drongo - fairwren has
> just gone green, and I expect drongo will when it reports in a few hours.
>
> I'm at a loss for an explanation.
>
I'm observing the same here (using a Windows 10 VM).
With no TEMP_CONFIG set, `meson test` gives me these numbers:
test: postgresql:pg_upgrade / pg_upgrade/002_pg_upgrade
duration: 72.34s
test: postgresql:regress / regress/regress
duration: 41.98s
But with debug_parallel_query=regress in TEMP_CONFIG, I see:
test: postgresql:regress / regress/regress
duration: 50.08s
test: postgresql:pg_upgrade / pg_upgrade/002_pg_upgrade
duration: 398.45s
With log_min_messages=DEBUG2 added to TEMP_CONFIG, I can see how many
parallel workers were started during the test:
...\postgresql\build>grep "starting background worker process" -r testrun/pg_upgrade | wc -l
17532
And another interesting fact is that TEMP_CONFIG is apparently ignored by
`meson test regress/regress`. For example, with temp.config containing
invalid settings, `meson test pg_upgrade/002_pg_upgrade` fails, but
`meson test regress/regress` passes just fine.
Best regards,
Alexander
