Andrew Dunstan <andrew@dunslane.net> writes:
> pgbfprod=# select sysname, snapshot from build_status_log where branch =
> 'HEAD' and log_stage = 'check.log' and log_text ~ $$\+ ERROR: canceling
> statement due to statement timeout$$;
> sysname | snapshot
> ---------+---------------------
> fennec | 2008-03-06 01:10:02
> heron | 2008-03-11 18:06:01
> heron | 2008-03-11 23:06:01
> heron | 2008-04-20 00:06:01
> cobra | 2008-04-26 04:15:02
> heron | 2008-04-27 00:06:01
> (6 rows)
Hmm, were there any matches in non-HEAD tests?
The log_disconnect records in these tests all seem to indicate that the
"reset" really did take a full second --- the total session time is
2-seconds-plus rather than 1-second-plus as in a successful run.
Since prepared_xacts runs as one member of a 20-way parallel test,
I guess it's not out of the question that the machine might sometimes
be loaded to the point where that backend doesn't get to run for awhile.
This would be particularly true if the kernel scheduler is one that
penalizes processes that it's decided are "background" processes ---
which might explain why certain platforms seem to show this more than
others.
Also, I trolled the CVS logs from 2008-03-06 back to the 8.3 branch point
and couldn't find anything that seemed likely to correspond to a large
performance dropoff.
So I'm kind of inclined to write this off as a testing glitch and "fix"
it by bumping the timeout up to 2 seconds. But it would be more
comforting if we'd seen it in back branches, or could spot some reason
why the test would be more likely to fail this way than in the past.
The prepared_xacts test itself hasn't changed materially since it was
put in...
regards, tom lane