RE: Fix 035_standby_logical_decoding.pl race conditions - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: Fix 035_standby_logical_decoding.pl race conditions
Date
Msg-id OS7PR01MB14968CC605A5FCDD678AD7661F5A62@OS7PR01MB14968.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Fix 035_standby_logical_decoding.pl race conditions  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Fix 035_standby_logical_decoding.pl race conditions
List pgsql-hackers
Dear Amit, Bertrand,

> Seeing all these failures, I wonder whether we can reliably test
> active slots apart from wal_level change test (aka Scenario 6:
> incorrect wal_level on primary.). Sure, we can try by having some
> injection point kind of tests, but is it really worth because, anyway
> the active slots won't get invalidated in the scenarios for row
> removal we are testing in this case. The other possibility is to add a
> developer-level debug_disable_running_xact GUC to test this and
> similar cases, or can't we have an injection point to control logging
> this WAL record? I have seen the need to control logging running_xact
> record in other cases as well.

Based on the idea which controls generating RUNNING_XACTS, I prototyped a patch.
When the instance is attached the new injection point, all processes would skip
logging the record. This does not need to extend injection_point module.
I tested with reproducer and passed on my env.
Sadly IS_INJECTION_POINT_ATTACHED() was introduced for PG18 so that the patch
could not backport for PG17 as-is.

How do you feel?

Best regards,
Hayato Kuroda
FUJITSU LIMITED


Attachment

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Allow default \watch interval in psql to be configured
Next
From: Daniel Gustafsson
Date:
Subject: Re: Allow default \watch interval in psql to be configured