From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Why doesn't src/backend/port/win32/socket.c implement bind()? |
Date: | 2016-04-13 22:56:39 |
Message-ID: | CAB7nPqQJv9XhhbMN2_LJHUz1QfkD3yg28TXe6QHcbesDHqs4cQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 13, 2016 at 10:33 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>> On Wed, Apr 13, 2016 at 9:06 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-04-13 23:02:20 | Re: fd.c: flush data problems on osx |
Previous Message | Stephen Frost | 2016-04-13 22:53:37 | Re: SET ROLE and reserved roles |