Re: More test/kerberos tweaks

Jacob Champion <pchampion(at)vmware(dot)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