Re: Suppressing occasional failures in copy2 regression test

On Mon, Jun 15, 2009 at 07:41:29PM +0530, Gurjeet Singh wrote:
> On Sun, Jun 14, 2009 at 12:39 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> > > Greg Stark <greg(dot)stark(at)enterprisedb(dot)com> writes:
> > >> I'm not sure about that. It seems like race conditions with autovacuum
> > >> are a real potential bug that it would be nice to be testing for.
> > >
> > > It's not a bug; it's a limitation of our testing framework that it sees
> > > this as a failure. Serious testing for autovac race conditions would
> > > indeed be interesting, but you're never going to get anything meaningful
> > > in that direction out of the current framework.
> >
> > The elephant in the room here may be moving to some more
> > flexible/powerful testing framework, but the difficulty will almost
> > certainly be in agreeing what it should look like. The actual writing
> > of said test framework will take some work too, but to some degree
> > that's a SMOP.
> >
> > This tuple-ordering issue seems to be one that comes up over and over
> > again, but in the short term, making it a TEMP table seems like a
> > reasonable fix.
> >
>
> I am forwarding a mail perl script and a pair of sample files that I
> developed about an year ago. The forwarded mail text explains what the
> script is trying to do. A line beginning with '?' in the expected file is
> treated specially.
>
> If a line begins with '?' then the rest of the line is treated as a regular
> expression which will be used to match the corresponding line from the
> actual output.
>
> If '?' is immediately followed by the word 'unordered' all the lines till a
> line containing '?/unordered' are buffered and compared against
> corresponding lines from the result file ignoring the order of the result
> lines.
>
> Although we at EnterpriseDB have resolved the issues by alternate files
> etc., and do not use this script, I think it might be useful for community
> regression tests.

I looked over the program. Here are a few observations:

* use strict; Good!

* Fails perlcritic <http://search.cpan.org/~elliotjs/Perl-Critic-1.098/bin/perlcritic>
at level 5: Bad!

* It's not using Tie::File <http://perldoc.perl.org/Tie/File.html>.
Probably bad.

* It's going to a lot of trouble to allow for the possibility of both
unordered results and of duplicate lines. If we disallow duplicate
lines in unordered result sets, we can get a big speed gain by using
hash-based comparisons.

* Thanks, Gurjeet! :)

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate