Re: Fix 035_standby_logical_decoding.pl race conditions

From: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fix 035_standby_logical_decoding.pl race conditions
Date: 2025-03-21 16:18:02
Message-ID: Z92ROjB3gEkXfhPf@ip-10-97-1-34.eu-west-3.compute.internal
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Kuroda-san,

On Fri, Mar 21, 2025 at 12:28:10PM +0000, Hayato Kuroda (Fujitsu) wrote:
> I'm also working on the thread to resolve the random failure.

Thanks for looking at it!

> I've also tried the idea with the living transaction via background_psql(),
> but I got the same result. The test could fail when RUNNING_XACTS record was
> generated before the transaction starts.

and thanks for testing and confirming too.

> SIGSTOP signal for pg_recvlogical may do the idea,

Yeah, but would we be "really" testing an "active" slot?

At the end we want to produce an invalidation that may or not happen on a real
environment. The corner case is in the test, not an issue of the feature to
fix.

So, I'm not sure I like the idea that much, but thinking out loud: I wonder if
we could bypass the "active" slot checks in 16 and 17 and use injection points as
proposed as of 18 (as we need the injection points changes proposed in 0001
up-thread). Thoughts?

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 Robert Haas 2025-03-21 16:21:13 Re: Parallel safety for extern params
Previous Message Peter Eisentraut 2025-03-21 16:15:05 Re: Update Unicode data to Unicode 16.0.0