Re: port conflicts when running tests concurrently on windows.
От | Andres Freund |
---|---|
Тема | Re: port conflicts when running tests concurrently on windows. |
Дата | |
Msg-id | 20211209184150.7gukmn36kgjrs565@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: port conflicts when running tests concurrently on windows. (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Ответы |
Re: port conflicts when running tests concurrently on windows.
|
Список | pgsql-hackers |
Hi, On 2021-12-09 14:35:37 +0100, Peter Eisentraut wrote: > On 09.12.21 03:44, Thomas Munro wrote: > > On Thu, Dec 9, 2021 at 11:46 AM Andres Freund<andres@anarazel.de> wrote: > > > 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? > > Makes sense to get this to work, at least as an option. With https://github.com/anarazel/postgres/commit/046203741803da863f6129739fd215f8a32ec357 all tests pass. pg_regress requires PG_REGRESS_SOCK_DIR because it checks for TMPDIR, but windows only has TMP and TEMP. > > Makes sense. As a data point, it looks like this feature is in all > > supported releases of Windows. It arrived in 1803, already EOL'd, and > > IIUC even a Windows Server 2016 "LTSC" system that's been disconnected > > from the internet and refusing all updates reaches "mainstream EOL" > > next month. > > I believe the "18" in "1803" refers to 2018. We have Windows buildfarm > members that mention 2016 and 2017 in their title. Would those be in > trouble? Perhaps it could make sense to print the windows version somewhere as part of a windows build? Perhaps in the buildfarm client? Seems like it could be generally useful, outside of this specific issue. The most minimal thing would be to just print cmd /c ver or such. systeminfo.exe output could also be useful, but has a bit of runtime (1.5s on my windows VM). Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: