A couple of regression test anomalies

During PGCon, Teodor asked me about a couple of odd behaviors in the
regression tests --- the output from Peter's code coverage tests was
showing that some GIN code he expected to be exercised wasn't.
After some poking around, I think we've narrowed it down to two
separate issues:

1. In create_index.sql, there's some tests that try to force use of
a plain indexscan, and then force use of a bitmapscan for the same
queries. Since GIN indexes no longer have amgettuple support, the
first group of these tests are dead code --- they end up executing
seqscans anyway.

We could rip out the dead tests. Or we could leave them there, on the
grounds that GIN amgettuple support might reappear someday. If we
do the latter, I'd be inclined to add comments to the test script
explaining the situation.

2. In tsearch.sql, there are multiple places where the test is trying
to exercise some just-created index. This works as expected if the
tests are run serially, but the indexes are (usually) not used if the
tests are run in parallel. The reason is that the table was UPDATEd
earlier in the test, so it has broken HOT chains, and other tests that
are run concurrently with this one usually have open transactions that
are older than the index.

There are a number of possible responses to #2, for instance:

2A. We could opine that this is not a bug; the whole point of running
parallel tests is to exercise code paths that are not taken in the
serial tests.

2B. We could try to avoid the broken-HOT-chain behavior, either by not
doing UPDATEs on the test table or by running this test by itself rather
than as part of a parallel group.

2C. We could try to force both code paths to be tested in either test
mode. However I'm not sure how we could do that in serial test mode.

2D. We could try to refine the indcheckxmin behavior so that it notices
that the indexes can be used anyway in this case. That would likely be
a bit too tricky for late beta, though, even if possible at all.

After some thought I'm leaning to the "not a bug" school of thought,
but I could probably be convinced otherwise.

Comments?

regards, tom lane