Andres Freund <andres@anarazel.de> writes:
> ISTM the issue at hand isn't so much that X expects something to be
> printed by Y before it terminates, but that it expects the next step to
> not be executed before Y unlocks. If I understand the wrong output
> correctly, what happens is that "controller_print_speculative_locks" is
> executed, even though s1 hasn't yet acquired the next lock.
That's one way to look at it perhaps.
I've spent the day fooling around with a re-implementation of
isolationtester that waits for all its controlled sessions to quiesce
(either wait for client input, or block on a lock held by another
session) before moving on to the next step. That was not a feasible
approach before we had the wait_event infrastructure, but it's
seeming like it might be workable now. Still have a few issues to
sort out though ...
regards, tom lane