RE: BUG: Former primary node might stuck when started as a standby - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: BUG: Former primary node might stuck when started as a standby
Date
Msg-id TYRPR01MB12156CC5A9AC774B07FA7E40BF57FA@TYRPR01MB12156.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: BUG: Former primary node might stuck when started as a standby  (Michael Paquier <michael@paquier.xyz>)
Responses Re: BUG: Former primary node might stuck when started as a standby
List pgsql-hackers
Dear Alexander, Michael,

> On Mon, Mar 02, 2026 at 09:00:00AM +0200, Alexander Lakhin wrote:
> > As it turned out, v2 patch works as expected, but the test may still fail
> > when the build is configured without injection points. Maybe this test (
> > and similar one(s)) should be skipped in this case, not sure...
>
> Exactly, I don't see what else we can do here except skip the
> sequences of the test that we know may fail if injection points are
> not enabled in the build.

I had a concern that some BF animals have not enable the injection point yet
thus coverage might be decreased for them. But it's OK for me to fix it.

> Looking at v2, the patch ought to comment the reason *why* these tests
> are skipped and *why* an injection point is used.  The reader should
> have more details than just a small hint about a set of "random
> failures".  I'd suggest to document that once with the first injection
> point attached, and have the other blocks hold comments telling to
> look at the first block.

I preferred to add descriptions at the place checking enable_injection_points.
See the updated version.

Best regards,
Hayato Kuroda
FUJITSU LIMITED


Attachment

pgsql-hackers by date:

Previous
From: Andreas Karlsson
Date:
Subject: Re: Use pg_malloc macros in src/fe_utils
Next
From: Boris Mironov
Date:
Subject: Re: Idea to enhance pgbench by more modes to generate data (multi-TXNs, UNNEST, COPY BINARY)