On Sun, Mar 26, 2023 at 10:49:33PM -0600, Markus Pilman wrote:
> I somehow didn't consider looking at the postgres tests, though it makes
> sense that they need to solve this problem. If I read the perl code
> correctly though it seems that this could, in theory, cause a race? The
> script checks first whether the port has been assigned to a test, then
> binds a socket to check whether it is used by someone else, closes this
> test socker, and then starts a server process. I guess it's unlikely
> enough, but isn't there a risk that some other process (that isn't
> controlled by this perl script) binds to the found port right after this
> test bind but right before postgres calls bind? I guess it should be rare
> enough so that it wouldn't cause flaky tests.
In theory, yes, I recall that's possible in the scripts. But only on
Windows where we cannot use socket directories and rely on SSPI
authentication while binding all the nodes to listen to 127.0.0.1. On
all the other platforms, each test creates its own directory that will
be used as path for unix_socket_directories. umask is 0700 and owned
by the OS user running the perl tests, so it is isolated as much as it
can be. Using the same port should be actually fine as far as I
recall, as long as the unix socket paths are different.
--
Michael
