port conflicts when running tests concurrently on windows.
От | Andres Freund |
---|---|
Тема | port conflicts when running tests concurrently on windows. |
Дата | |
Msg-id | 20211208224550.jh4lbcbjsnukwatq@alap3.anarazel.de обсуждение исходный текст |
Ответы |
Re: port conflicts when running tests concurrently on windows.
Re: port conflicts when running tests concurrently on windows. |
Список | pgsql-hackers |
Hi, With the meson patch applied the tests on windows run concurrently by default. Unfortunately that fails semi-regularly. The reason for this basically is that windows defaults to using TCP in tests, and that the tap-test port determination is very racy: > # When selecting a port, we look for an unassigned TCP port number, > # even if we intend to use only Unix-domain sockets. This is clearly > # necessary on $use_tcp (Windows) configurations, and it seems like a > # good idea on Unixen as well. > $port = get_free_port(); > ... > =item get_free_port() > > Locate an unprivileged (high) TCP port that's not currently bound to > anything. This is used by C<new()>, and also by some test cases that need to > start other, non-Postgres servers. > > Ports assigned to existing PostgreSQL::Test::Cluster objects are automatically > excluded, even if those servers are not currently running. > > XXX A port available now may become unavailable by the time we start > the desired service. I don't think there's an easy way to make this race-free. We'd need to teach postmaster to use pre-opened socket or something like that. An alternative to that would be to specify a base port number externally. In the meson branch I already did that for the pg_regress style tests, since they don't have the automatic port thing above. But for tap tests there's currently no way to pass in a base-port that I can see. Is it perhaps time to to use unix sockets on windows by default (i.e. PG_TEST_USE_UNIX_SOCKETS), at least when on a new enough windows? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: