Silly little tool for making parallel_schedule variants - Mailing list pgsql-hackers

From Tom Lane
Subject Silly little tool for making parallel_schedule variants
Date
Msg-id 25153.1035318719@sss.pgh.pa.us
Whole thread Raw
List pgsql-hackers
I got tired of wondering what timing dependencies might still be lurking
in the parallel regression tests, and wrote a little Perl script to find
out by making variant versions of the parallel_schedule file.

Essentially, the script forces each test in a parallel group to run
before all the other ones in its group, and also after all the other
ones.  This isn't a completely bulletproof check: you could imagine
that test A might be unhappy about some intermediate state created by
test B, while not being unhappy with either the starting or ending
states.  But it's a lot better than guess-and-hope.

The script successfully exposed the problem reported earlier today by
Robert Hentosh (create_index test depends on create_misc having run),
and didn't find any other problems, which I guess is a good sign.
(I've now committed a fix for that mistake, BTW.)

I'm not sure if the script has any long-term usefulness (anyone feel it
deserves to get into CVS in src/tools/?).  But I'll attach it anyway
just so it gets into the pghackers archives.

To use it you'd do something like

mkdir scheds
./sched_variants parallel_schedule scheds/sch
for f in scheds/sch*
do
    echo $f
    /bin/sh ./pg_regress --schedule=$f
    ff=`basename $f`
    mv regression.out scheds/regression.out.$ff
    mv regression.diffs scheds/regression.diffs.$ff
done


            regards, tom lane

#! /usr/bin/perl

# Generate variants of parallel_schedule file to verify that there are
# no order dependencies between tests executed in parallel.

# Usage: sched_variants input_file output_prefix

# Output files are named with 'output_prefix' suffixed .1, .2, etc.

die "Usage: sched_variants input_file output_prefix\n" if ($#ARGV != 1);

$infile = $ARGV[0];
$outprefix = $ARGV[1];

$outcount = 0;            # number of output files created

# We scan the input file repeatedly.  On each pass we generate two
# output files, one where the k'th entry of each parallel test set
# has been extracted and forced to run first, and one where it's been
# forced to run last.  The number of passes needed is the same as the
# largest number of tests in a parallel test set.

$k = 1;                # test index we are currently hacking

$more = 1;            # true if we need another pass

while ($more) {
    $more = 0;            # until proven differently

    open(INFILE, $infile) || die "$infile: $!\n";

    $outcount++;
    $outbefore = $outprefix . "." . $outcount;
    open(OUTBEFORE, "> $outbefore") || die "$outbefore: $!\n";

    $outcount++;
    $outafter = $outprefix . "." . $outcount;
    open(OUTAFTER, "> $outafter") || die "$outafter: $!\n";

    while (<INFILE>) {
    if (! /^test:/) {
        # comment line
        print OUTBEFORE $_;
        print OUTAFTER $_;
        next;
    }
    @tests = split;
    shift(@tests);        # remove test:
    if ($#tests < $k-1 || $#tests == 0) {
        # too few tests in this set, just repeat as-is
        print OUTBEFORE $_;
        print OUTAFTER $_;
        next;
    }
    if ($#tests >= $k) {
        $more = 1;        # need more passes to process this set
    }
    @thistest = splice(@tests, $k-1, 1);
    print OUTBEFORE "test: @thistest\n";
    print OUTBEFORE "test: @tests\n";

    print OUTAFTER "test: @tests\n";
    print OUTAFTER "test: @thistest\n";
    }

    close OUTBEFORE;
    close OUTAFTER;
    close INFILE;

    $k++;
}

print "$outcount test files generated.\n";

exit 0;

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: One 7.3 item left
Next
From: Greg Copeland
Date:
Subject: Memory leaks