Re: POC: Better infrastructure for automated testing of concurrency issues
От | Alexander Korotkov |
---|---|
Тема | Re: POC: Better infrastructure for automated testing of concurrency issues |
Дата | |
Msg-id | CAPpHfdvQyiD+Nr2hOCKNyYnijPEep0uQ8LthAEJGTAiF=bJHmw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: POC: Better infrastructure for automated testing of concurrency issues (Andrey Borodin <x4mmm@yandex-team.ru>) |
Список | pgsql-hackers |
On Tue, Dec 8, 2020 at 1:26 PM Andrey Borodin <x4mmm@yandex-team.ru> wrote: > > 25 нояб. 2020 г., в 19:10, Alexander Korotkov <aekorotkov@gmail.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 likethat. > I'm not really sure it's useful, just an idea. Thank you for your feedback! I forgot to mention, patch comes with pg_stopevents() function which returns rowset (stopevent text, condition jsonpath, waiters int[]). Waiters is an array of pids of waiting processes. Additionally, isolation tester checks if a particular backend is waiting using pg_isolation_test_session_is_blocked(), which works with stop events too. ------ Regards, Alexander Korotkov
В списке pgsql-hackers по дате отправления: