Re: More test/kerberos tweaks - Mailing list pgsql-hackers

From Tom Lane
Subject Re: More test/kerberos tweaks
Date
Msg-id 133280.1612558520@sss.pgh.pa.us
Whole thread Raw
In response to More test/kerberos tweaks  (Jacob Champion <pchampion@vmware.com>)
Responses Re: More test/kerberos tweaks
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Key management with tests
Next
From: Robert Haas
Date:
Subject: Re: making update/delete of inheritance trees scale better