Re: isolation tester limitation in case of multiple injection points in a single command - Mailing list pgsql-hackers

From Mihail Nikalayeu
Subject Re: isolation tester limitation in case of multiple injection points in a single command
Date
Msg-id CADzfLwVCS05PWf1BfAd4niZaz_VE3pHw-MBokpB2p+nwKb-XOQ@mail.gmail.com
Whole thread Raw
In response to Re: isolation tester limitation in case of multiple injection points in a single command  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Hi!

(sorry, I accidentally pressed "reply" instead "reply all) - sent again

Michael Paquier <michael@paquier.xyz> wrote:
>
> FWIW, I think that it's OK to use as style.  The backend-side
> injection point implementation is currently quite simple, meaning that
> it less prone to future bugs.  For testing purposes, that's an
> important property to rely on, IMO.


Just realized that my need is not possible to achieve using multiple
injection points in a row (or different types for the same injection
point) in a race-free way.

This is because I need to receive `notice` BEFORE the backend goes
into `wait` but ONLY AFTER it is guaranteed for WAKE_UP to be
successful.
Yes, the probability of such a race is really low, but still...

So, NOTICE should be sent at [0] while holding spin lock. What do you
think about adding an optional parameter to raise NOTICE with wait?
But it feels weird with the 'notice' type itself...

Any thoughts? Or just ignore that potential low-probability race +
some comments in the test?

Best regards,
Mikhail.

[0]:
https://github.com/postgres/postgres/blob/4eca711bc991954613261b7a314b1e8f5963815c/src/test/modules/injection_points/injection_points.c#L315



pgsql-hackers by date:

Previous
From: Junwang Zhao
Date:
Subject: Adjust comments for `IndexOptInfo` to accurately reflect indexcollations's length
Next
From: Álvaro Herrera
Date:
Subject: Re: Extended test coverage and docs for SSL passphrase commands