Re: Why doesn't src/backend/port/win32/socket.c implement bind()?
От | Michael Paquier |
---|---|
Тема | Re: Why doesn't src/backend/port/win32/socket.c implement bind()? |
Дата | |
Msg-id | CAB7nPqQJv9XhhbMN2_LJHUz1QfkD3yg28TXe6QHcbesDHqs4cQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Why doesn't src/backend/port/win32/socket.c implement bind()? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Why doesn't src/backend/port/win32/socket.c implement
bind()?
|
Список | pgsql-hackers |
On Wed, Apr 13, 2016 at 10:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paquier@gmail.com> writes: >> On Wed, Apr 13, 2016 at 9:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> If there's other stuff using high ports on a particular buildfarm machine, >>> you'd expect occasional random test failures due to this. The observed >>> fact that some buildfarm critters are much more prone to this type of >>> failure than others is well explained by this hypothesis. > >> Each test run uses its own custom unix_socket_directories, PGHOST is >> enforced to use it, and all the port tests go through that as well. > > By that argument, we don't need the free-port-searching code on Unix at > all. But this discussion is mostly about Windows machines. Well, yes. That's true, we could do without. Even if this could give an indication about a node running, as long as a port has been associated to a node once, we just need to be sure that a new port is not allocated. On Windows, I am not sure that it is worth the complication to be honest, and the current code gives a small safety net, which is better than nothing. -- Michael
В списке pgsql-hackers по дате отправления: