Обсуждение: Remove condition variables from injection wait logic.

$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] https://www.postgresql.org/message-id/aKT7qD0VkGhQgFJe%40paquier.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
criticalsection. 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.