Hello, everyone! While stabilizing tests for [0] I realized I have no idea how to set up a pretty simple scenario using an isolation tester.
It looks like this: * session S1 start long running query (CREATE INDEX CONCURRENTLY) and traps into injection point X * session S2 executes some command * session S2 wakes up S1 * now S2 needs to run one more command BUT only AFTER S1 traps into another injection point Y (and it is still the same CREATE INDEX) <------- tricky part here My first idea was to add one more injection point Z with 'notice' type before Y (not a bulletproof way, but okay for now) - and use some S2_noop (S1 notices 1) step.... But AFAIU injection_point's 'notice' is a totally different type of notice compared to RAISE NOTICE - so, isolation_tester just ignores it. Second idea is to implement some polling procedure to find S1 waiting in pg_stat_activity... But that feels weird for a spec test. Maybe we should implement some injection_point_await utility? So, my proposal options: a) tell me if there's a clear solution I missed b) for 'wait' injection_point - learn isolation tester to detect it and implement logic like 'S2_query(S1 traps Y)' c) learn isolation tester to treat 'notice' from injection_point the same way as RAISE NOTICE + (preferable) add possibility to apply 'notice' and 'wait' for the same injection point (like 'wait+notice') d) add injection_point_await - utility to wait until injected point is not "waited" by some backend What do you think? Any other ideas? Best regards, Mikhail. [0]: https://commitfest.postgresql.org/patch/5160/
