On 05/19/2014 05:37 PM, Tomas Vondra wrote:
IMHO the problem is that d6a97674 was the last revision in the REL9_3_STABLE branch when the test started (00:14), but at 06:06 777d07d7 got committed. So the check at the end failed, because the tested revision was suddenly ~2 days over the limit. This seems wrong to me, because even a very fast test including the commit (e.g. starting at 06:00, finishing at 06:10) would fail exactly like this. This is more probable on the old stable branches, because the commits are not that frequent (on HEAD the commits are usually less than a few hours apart, so the new one won't obsolete the previous one). It's also made more likely to hit by the long runtime, because it increases the probability something will be committed into the branch. And it also makes it more "expensive" because it effectively throws all the cpu time to /dev/null.
Well, the original code was put in for a reason, presumably that we were getting some stale data and wanted to exclude it. So I'm unwilling to throw it out altogether. If someone can propose a reasonable sanity check then I'm prepared to implement it.
cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
