isolation tester limitation in case of multiple injection points in a single command
| От | Mihail Nikalayeu |
|---|---|
| Тема | isolation tester limitation in case of multiple injection points in a single command |
| Дата | |
| Msg-id | CADzfLwUc=jtSUEaQCtyt8zTeOJ-gHZ8=w_KJsVjDOYSLqaY9Lg@mail.gmail.com обсуждение исходный текст |
| Ответы |
Re: isolation tester limitation in case of multiple injection points in a single command
|
| Список | pgsql-hackers |
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')
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/
What do you think? Any other ideas?
Best regards,
Mikhail.
[0]: https://commitfest.postgresql.org/patch/5160/
В списке pgsql-hackers по дате отправления: