Re: POC: Better infrastructure for automated testing of concurrency issues - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: POC: Better infrastructure for automated testing of concurrency issues
Date
Msg-id CAPpHfdvQyiD+Nr2hOCKNyYnijPEep0uQ8LthAEJGTAiF=bJHmw@mail.gmail.com
Whole thread Raw
In response to Re: POC: Better infrastructure for automated testing of concurrency issues  (Andrey Borodin <x4mmm@yandex-team.ru>)
List 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 by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: POC: Better infrastructure for automated testing of concurrency issues
Next
From: Amit Kapila
Date:
Subject: Re: [Patch] Optimize dropping of relation buffers using dlist