More test/kerberos tweaks
| От | Jacob Champion |
|---|---|
| Тема | More test/kerberos tweaks |
| Дата | |
| Msg-id | fe7a46f8d46ebb074ba1572d4b5e4af72dc95420.camel@vmware.com обсуждение исходный текст |
| Ответы |
Re: More test/kerberos tweaks
|
| Список | pgsql-hackers |
While working on [1] I ended up running into a couple issues with the Kerberos test suite. Attached are two patches with possible improvements: Some tests check for expected log messages. They currently search through the entire log file, from the beginning, for every match. So if two tests share the same expected log content (which is common), it's possible for the second test to get a false positive by matching against the first test's output. (You can see this by modifying one of the expected-failure tests to expect the same output as a previous happy-path test.) The first patch stores the offset of the previous match, and searches forward from there during the next match, resetting the offset every time the log file changes. This isn't perfect -- it could still result in false positives if one test spits out two or more matching log lines and only matches the first one by itself -- but searching forward should be an improvement over what's there now. 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. --Jacob [1] https://www.postgresql.org/message-id/a9ee5e4e8e844d06c2bcf70c6ed3306ccb4897f1.camel%40vmware.com
Вложения
В списке pgsql-hackers по дате отправления: