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@gmail.com> wrote:
> 
> > > Greg Stark <greg.stark@enterprisedb.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
disallowduplicate lines in unordered result sets, we can get a big speed gain by using hash-based comparisons.
 

* Thanks, Gurjeet! :)

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

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