Remove condition variables from injection wait logic.
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t52129psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 08:06 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t52129_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t52129_1 && git checkout t52129_1Patchset v1 (message #1) is on t52129_1
$sub proposed in a nearby thread. Looks like we have a consensus that
$subj is beneficial.
I implemented necessary legwork, namely a clock-based check in the
wait() routine, PFA. I'm not sure the default pg_sleep argument of 50
millisecond is good, but it is fast enough to not spot any difference
in by-hand testing.
[0]: /messages/by-id/aKT7qD0VkGhQgFJe@paquier.xyz
--
Best regards,
Kirill Reshke
On Wed, Aug 20, 2025 at 11:20:11AM +0500, Kirill Reshke wrote:
$sub proposed in a nearby thread. Looks like we have a consensus that
$subj is beneficial.
I implemented necessary legwork, namely a clock-based check in the
wait() routine, PFA. I'm not sure the default pg_sleep argument of 50
millisecond is good, but it is fast enough to not spot any difference
in by-hand testing.
I may be missing something, but I don't think that we have reached a
consensus yet. There is the argument of AIO and being able to
broadcast writes.
+ pgstat_report_wait_start(injection_wait_event);
+#define DEFAULT_INJ_POINT_SLEEP_MICROSEC 50000L /* 50 milliseconds */
+ pg_usleep(DEFAULT_INJ_POINT_SLEEP_MICROSEC);I would not object to that if that's the actual consensus as we don't
have a strong requirement for condition variables when it comes to
testing. That's just a more efficient implementation, and it makes
the tests faster. If we do that, I'd suggest to choose a cap and a
variable wait time, that increases across iterations to still make the
wait more responsive on faster machines.
Your patch lacks a pgstat_report_wait_end().
--
Michael
On 21 Aug 2025, at 04:02, Michael Paquier <michael@paquier.xyz> wrote:
I would not object to that if that's the actual consensus as we don't
have a strong requirement for condition variables when it comes to
testing. That's just a more efficient implementation, and it makes
the tests faster. If we do that, I'd suggest to choose a cap and a
variable wait time, that increases across iterations to still make the
wait more responsive on faster machines.
I want to do a test for suspected VM corruption (1).
I need a way to do injection point that can be kill-9-ed without corruption.
So I can just use Kirill's patch to develop my test, thanks! I do not need it committed until the work is over.
So far there are no tests in the tree that need this functionality in injection points.
And even when we will have such a test that needs this kind of sleep, it is only required if injection point is in critical section. Not for every injection point wait.
Also, CondVar might be fixed and allowed to be used in critical section (2). AIO needs it anyway.
Let's wait for (1) or (2), then decide if we need to do something with injection point waiting.
Thanks you both for working on these tools!
Best regards, Andrey Borodin.