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