Re: A couple of random BF failures in kerberosCheck
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2019-08-03T22:42:48Z
Lists: pgsql-hackers
Attachments
- select-unused-port-1.patch (text/x-diff) patch
I wrote: > * kerberos/t/001_auth.pl just blithely assumes that it can pick > any random port above 48K and that's guaranteed to be free. > Maybe we should split out the code in get_new_node for finding > a free TCP port, so we can call it here? I've confirmed that the reason it's failing on my machine is exactly that krb5kdc tries to bind to a socket that is still in TIME_WAIT state. Also, it looks like the socket is typically one that was used by the GSSAPI client side (no surprise, the test leaves a lot more of those than the one server socket), so we'd have no record of it even if we were somehow saving state from prior runs. So I propose the attached patch, which seems to fix this for me. The particular case I'm looking at (running these tests in a tight loop) is of course not that interesting, but I argue that it's just increasing the odds of failure enough that I can isolate the cause. A buildfarm animal running both kerberos and ldap tests is almost certainly at risk of such a failure with low probability. (Still don't know what actually happened in those two buildfarm failures, though.) regards, tom lane
Commits
-
Avoid picking already-bound TCP ports in kerberos and ldap test suites.
- 803466b6ffaa 13.0 landed
- 4844c6303296 12.0 landed
- 45d6789e78dc 11.5 landed