Re: Further stabilization of isolationtester's timeouts test

On 2016-05-27 04:06, Tom Lane wrote:

> In this case the process seems to have gone to sleep for just short of a
> minute rather than the expected 5 seconds. Presumably that just reflects
> overload on the buildfarm member rather than anything really exciting,
> but it explains the failure nicely: by the time we got to postgres.c's
> ProcessInterrupts(), both the lock and statement timeouts had expired,
> and the code there preferentially reports "lock timeout" in that case.

Just wanted to chip in and say that it's almost certain due to
overloading. It's a virtual server (VMWare) that runs 4 build animals
and they all where scheduled to run at the same time and it's on
spinning rust (i.e. HDD) so it will get overloaded easilly.

I've changed the schedules of the 4 animals so that they shouldn't
overloap so from now on it should hopefully be much better.

/Mikael