John Gray <jgray@azuli.co.uk> writes:
> I agree with this, but I think an earlier suggestion of Manfred's,
> (namely tests that explicitly check concurrency issues) might be useful
> to verify the integrity of MVCC.
Indeed, we could use some sort of parallel-testing harness to allow
fine-grained verification of concurrent behavior. This has been
discussed several times, but no one's stepped up to the plate.
Your sketch misses an important point: we want to know not only what
each backend does, but when it does it. (For example, we'd want the
test harness to be able to check that LOCK actually prevents another
backend from making progress.) A brute-force way to do that would be
to delay for some amount of time between issuing commands, so that we
can be sure the backends have reached a quiescent state. Then, logging
all the commands and responses serially into a single file would provide
some idea of causal order. It could still be tricky though, eg if an
unlock releases two other backends then their results could arrive in
either order.
regards, tom lane
