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

From: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
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 07:59:31
Message-ID: ZyCV42uwpq6yStt/@ip-10-97-1-34.eu-west-3.compute.internal
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Tue, Oct 29, 2024 at 01:12:25PM +0900, Michael Paquier wrote:
> 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.

Agree.

> > 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.

Right.

> 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.

Yeah, not ideal so better to keep the test as it is currently (after your
refactoring).

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

That sounds like it, agree.

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2024-10-29 08:06:32 Remove useless casts to (void *)
Previous Message Hayato Kuroda (Fujitsu) 2024-10-29 07:59:04 RE: Conflict detection for update_deleted in logical replication