From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
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:41:56 |
Message-ID: | CAPpHfdvQyiD+Nr2hOCKNyYnijPEep0uQ8LthAEJGTAiF=bJHmw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Dec 8, 2020 at 1:26 PM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
> > 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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2020-12-08 10:58:41 | Re: [Patch] Optimize dropping of relation buffers using dlist |
Previous Message | Andrey Borodin | 2020-12-08 10:26:27 | Re: POC: Better infrastructure for automated testing of concurrency issues |