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 <t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
