Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am seeing the following parallel regression test failures. Any idea
> on the cause?
For the record, I believe this is explained by the bug I just fixed in
_bt_search().
The bug occurs only when one backend is trying to search a btree index
at the same time another backend is doing the first page split in that
index (that is, when the aboriginal root-and-leaf page gets split into
two leaf pages). In the present form of the parallel regression tests,
pg_class_oid_index and pg_type_oid_index suffer that split during the
third group of parallel tests, which is why the failures were bunched
in constraints/triggers/vacuum.
My guess is that the reason different vintages of CVS show or don't show
the problem is that modifications of the test scripts have caused more
or fewer pg_class and pg_type entries to get created, possibly moving
the critical split point before or after that set of parallel tests.
If the split occurs during a sequential test step then we'd never see
a failure. This may explain why we've not become aware of the bug till
now, even though it's certainly been there a long time.
We need to think about whether this bug is serious enough to justify a
quick 7.3.5 release. I'm leaning to the idea that it is not, because
if it were, we'd have heard about it from the field before now. In
pre-7.4 code there is only one instant in the lifespan of an index where
the bug could occur, and then only if the index is created empty.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
