FAQ
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

Search Discussions

  • Peter Eisentraut at May 27, 2009 at 9:09 pm

    On Monday 25 May 2009 00:55:17 Tom Lane wrote:
    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.
    It might be useful to add another test case that exercises the other code path
    in parallel mode anyway, e.g., a similar table that is not updated earlier in
    the test.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMay 24, '09 at 9:55p
activeMay 27, '09 at 9:09p
posts2
users2
websitepostgresql.org...
irc#postgresql

2 users in discussion

Peter Eisentraut: 1 post Tom Lane: 1 post

People

Translate

site design / logo © 2022 Grokbase