Jacob Champion <pchampion@vmware.com> writes:
> The second patch is more of a quality-of-life improvement for devs. On
> a failed log match, the test will spin for three minutes before giving
> up on the match. I think this is excessive, especially since
> interrupting the test with Ctrl-C leaves behind a running KDC daemon.
> The patch reduces the timeout to three seconds. I guess the only
> question I have is whether there are any underpowered machines out
> there running this test, relying on the higher timeout to function.
We have, almost invariably, regretted it when we tried to use short
timeouts in test cases.
I checked the buildfarm logs for the past month to see which machines
are running the kerberos test and what their reported stage runtimes
were. There are just three:
system min time max time
crake | 00:00:09 | 00:01:16
eelpout | 00:00:00 | 00:00:01
elver | 00:00:04 | 00:00:09
I'm not sure what's happening on crake to give it such a wide range
of runtimes on this test, but I can't help thinking it would probably
have failed a few of those runs with a three-second timeout.
More generally, sometimes people want to do things like run a test
under valgrind. So it's not just "underpowered machines" that may
need a generous timeout. Even if we did reduce the default, I'd
want a way (probably via an environment variable, cf PGCTLTIMEOUT)
to kick it back up.
On the whole, I think the right thing to be doing here is not so
much messing with the timeout as fixing the test script to be
more robust against control-C. If it's failing to shut down the
KDC, I'd say that's a test bug.
regards, tom lane