Re: Add isolation test template in injection_points for wait/wakeup/detach

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add isolation test template in injection_points for wait/wakeup/detach
Date: 2024-10-29 04:12:25
Message-ID: ZyBgqdNbkmsyD4TB@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 28, 2024 at 07:17:28AM +0000, Bertrand Drouvot wrote:
> I think that we can not be 100% sure that the s1 wait will finish before the
> s2 detach (easy reproducible with gdb attached on s1 or an hardcoded sleep) and
> that other OS could also report the test as failing for the same reason.

Yes, the only safe thing we can do in this test is to let the wakeup2
be last, as we are sure that the isolationtester is going to keep at
s2 to finish the call of the wakeup function before moving on with
checking the end of the wait.

> It's not ideal, but instead of removing this first permutation test what about
> adding a "sleep2" step in it (doing say, SELECT pg_sleep(1);) and call this
> new step before the detach2 one?

There is no real guarantee of stability. Under a wait of N seconds,
we could still have environments where the wait() could remain stuck
more than N seconds between the moment the condition variable is woken
up and the result of the wait() is reported back to the client. And
hardcoded sleeps make the test slower even on fast machines.

What we have here seems like just contention of Cirrus with the
FreeBSD hosts while there is much more stability with the linux hosts.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2024-10-29 04:23:46 Re: Pgoutput not capturing the generated columns
Previous Message cca5507 2024-10-29 03:21:15 Re: Reduce one comparison in binaryheap's sift down