Greg Stark <greg.st...@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.
> Another solution would be adding an order by clause - effectively
> trading coverage of unordered raw scans for coverage of the vacuum
> races.
And destroying one of the main points of the copy2 test, which is that
those triggers are supposed to fire in a specific order.
> 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.
There are several variants already observed, I believe, and I have
little confidence that there aren't more. In any case, that's a kluge
not a solution, and it still degrades the ability of the test to cover
what it was designed to cover.
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
