Heikki Linnakangas wrote:
> I converted the next test, receipt-report, grab that from my git
> repository first. It produces over two hundred permutations, so
> it's going to be a bit tedious to check the output for that, but I
> think it's still acceptable so that we don't need more complicated
> rules for what is accepted.
I was a bit disconcerted to see 48 permutations fail when dcheck had
been seeing 6; but it turned out to be simple to fix -- the third
connection was declared READ ONLY in the dcheck version. Measuring
false positives for the READ WRITE version is probably valuable, but
we also want to test the READ ONLY optimizations. The "two ids test"
has similar dynamics, so I'll change one or the other so we cover
both scenarios.
> IOW, we can just print the output of all permutations and "diff",
> we won't need "if step X ran before step Y, commit should succeed"
> rules that the python version had.
I found two problems with this, and I'm not sure how to handle
either. If we can figure out an approach, I'm happy to work on it.
(1) We don't have much in the way of detail yet. I put a different
detail message on each, so that there is more evidence, hopefully at
least somewhat comprehensible to an educated user, about how the
cancelled transaction fit into the dangerous pattern of access among
transactions. Ultimately, I hope we can improve these messages to
include such detail as table names in many circumstances, but that's
not 9.1 material. What I did include, when it was easily available,
was another xid involved in the conflict. These are not matching
from one test to the next.
(2) The NOTICE lines for implicit index creation pop up at odd times
in the output, like in the middle of a SQL statement. It looks like
these are piling up in a buffer somewhere and getting dumped into the
output when the buffer fills. They are actually showing up at
exactly the same point on each run, but I doubt that we can count on
that for all platforms, and even if we could -- it's kinda ugly.
Perhaps we should change the client logging level to suppress these?
They're not really important here.
So, I think (2) is probably easy, but I don't see how we can deal
with (1) as easily. Suppress detail? Filter to change the xid
number to some literal?
-Kevin