Peter Geoghegan <pg@bowt.ie> writes:
> On Wed, Apr 10, 2019 at 4:56 PM Peter Geoghegan <pg@bowt.ie> wrote:
>> The original fastpath tests don't seem particularly effective to me,
>> even without the oversight I mentioned. I suggest that you remove
>> them, since the minimal btree_index.sql fast path test is sufficient.
> To be clear: I propose that you remove the tests entirely, and we
> leave it at that. I don't intend to follow up with my own patch
> because I don't think that there is anything in the original test case
> that is worth salvaging.
I checked into this by dint of comparing "make coverage" output for
"make check" runs with and without indexing.sql's fastpath tests.
There were some differences that seem mostly to be down to whether
or not autovacuum hit particular code paths during the test run.
In total, I found 29 lines that were hit in the first test but not
in the second ... and 141 lines that were hit in the second test
but not the first. So I concur that indexing.sql's fastpath test
isn't adding anything useful coverage-wise, and will just nuke it.
(It'd be interesting perhaps to check whether the results shown
by coverage.postgresql.org are similarly unstable. They might be
less so, since I believe those are taken over the whole check-world
suite not just the core regression tests.)
regards, tom lane