Alvaro Herrera <[EMAIL PROTECTED]> writes: > Also note this message: >> If this theory is correct, then we can improve the reliability of the >> stats test a good deal if we put a sleep() at the *start* of the test, >> to let any old backends get out of the way. It seems worth a try >> anyway. I'll add this to HEAD and if the stats failure noise seems to >> go down, we can back-port it.
> Apparently it wasn't enough to completely eliminate the problems. Did > it reduce them? I haven't been watching the buildfarm closely enough to > know for sure. It doesn't seem to have helped much if at all :-(. The $64 question in my mind is whether the failures represent pgstats not working at all, or just being pretty slow when the system is under load. It seems likely to be the latter, but ... I don't want to just keep jacking the sleep up indefinitely, anyway; that will slow the regression tests down for little reason. I'm tempted to propose replacing the fixed sleep with a short plpgsql function that sleeps for a second, checks to see if the stats have changed, repeats if not; giving up only after perhaps 30 seconds. It'd be interesting to try to gather stats on the length of the delay taken, but I don't see a good way to do that within the current regression-test infrastructure. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match