Re: Suppressing occasional failures in copy2 regression test

Sorry for top-posting -- stupid apple mail client...

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.

Another solution would be adding an order by clause - effectively  
trading coverage of unordered raw scans for coverage of the vacuum  
races.

Or a third option would be adding alternate outputs for each ordering  
we observe. I suspect there aren't that many for serial tests but I'm  
less confident of that for the parallel tests.

-- 
Greg


On 13 Jun 2009, at 17:27, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Every so often the buildfarm shows row-ordering differences in the  
> copy2
> test, for example
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=jaguar&dt=2009-06-13%2003:00:02
> ("jaguar" seems particularly prone to this for some reason, but other
> members have shown it too.)  I believe what is happening is that
> autovacuum chances to trigger on the table being used, allowing some  
> of
> the updated rows to be placed in positions they're not normally placed
> in.
>
> There is a simple fix for that: change the table to be a temp table,
> thus preventing autovac from touching it.
>
> Any objections to doing that?
>
>            regards, tom lane
>
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers