| From: | Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: isolation tester limitation in case of multiple injection points in a single command |
| Date: | 2025-11-22 12:52:17 |
| Message-ID: | CADzfLwVCS05PWf1BfAd4niZaz_VE3pHw-MBokpB2p+nwKb-XOQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi!
(sorry, I accidentally pressed "reply" instead "reply all) - sent again
Michael Paquier <michael(at)paquier(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Álvaro Herrera | 2025-11-22 13:00:55 | Re: Extended test coverage and docs for SSL passphrase commands |
| Previous Message | Junwang Zhao | 2025-11-22 12:44:13 | Adjust comments for `IndexOptInfo` to accurately reflect indexcollations's length |