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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
