Re: isolation tester limitation in case of multiple injection points in a single command
| От | Mihail Nikalayeu |
|---|---|
| Тема | Re: isolation tester limitation in case of multiple injection points in a single command |
| Дата | |
| Msg-id | CADzfLwVCS05PWf1BfAd4niZaz_VE3pHw-MBokpB2p+nwKb-XOQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: isolation tester limitation in case of multiple injection points in a single command (Michael Paquier <michael@paquier.xyz>) |
| Список | 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 по дате отправления: