| From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
|---|---|
| To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: POC: Better infrastructure for automated testing of concurrency issues |
| Date: | 2020-12-08 10:26:27 |
| Message-ID: | 108FA78A-BA42-4F17-BCC5-F9ACA472DEA3@yandex-team.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Alexander!
> 25 нояб. 2020 г., в 19:10, Alexander Korotkov <aekorotkov(at)gmail(dot)com> написал(а):
>
> In the code stop events are defined using macro STOPEVENT(event_id, params). The 'params' should be a function call, and it's evaluated only if stop events are enabled. pg_isolation_test_session_is_blocked() takes stop events into account. So, stop events are suitable for isolation tests.
Thanks for this infrastructure. Looks like a really nice way to increase test coverage of most difficult things.
Can we also somehow prove that test was deterministic? I.e. expect number of blocked backends (if known) or something like that.
I'm not really sure it's useful, just an idea.
Thanks!
Best regards, Andrey Borodin.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2020-12-08 10:41:56 | Re: POC: Better infrastructure for automated testing of concurrency issues |
| Previous Message | Amit Kapila | 2020-12-08 10:16:05 | Re: Single transaction in the tablesync worker? |