Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Feb 12, 2016 at 4:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The fundamental problem I fear is that isolationtester is designed around
>> the assumption that only its own actions (query issuances) change the
>> state of the database. Trying to use it to test deadlock detection is
>> problematic because deadlock-breaking changes the DB state asynchronously.
> Maybe we should introduce a way to declare whether a step is expected
> to wait or not. I thought about doing that, and the only reason I
> didn't is because I couldn't figure out a reasonable syntax. But, in
> many respects, that would actually be better than the current system
> of having isolationtester try to figure it out itself.
Meh. I'm not sure that would actually help anything. The problem is not
so much with figuring out whether a step blocks, as knowing when it's
expected to complete. And for sure I don't want to annotate the spec
files to the point of saying "this action should cause these other steps
to complete".
Actually ... the thing we've been fighting over the past couple days is
having to make step completion orders deterministic when in principle
they aren't and don't need to be. Maybe the solution is something like
the core tests' variant expected files, ugly though those are.
regards, tom lane