Magnus Hagander <mag...@hagander.net> writes: > On Mon, Jan 11, 2016 at 6:19 AM, Amit Kapila <amit.kapil...@gmail.com> > wrote: >> On Sun, Jan 10, 2016 at 11:55 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I think the reason why we're getting "No error" instead of a useful >>> strerror report is that socket.c doesn't provide an implementation >>> of bind() that includes TranslateSocketError().
>> listen also doesn't have such an implementation and probably few others. >> I think here we should add a win32 wrapper over bind and listen >> API's which ensures TranslateSocketError() should be called for >> error cases. > Yeah, that seems like a good idea. I finally got around to doing this, after being annoyed by yet another Windows buildfarm failure with no clear indication as to the cause: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2016-04-12%2022%3A30%3A12 While we wait to see if that actually helps give useful errors, I had a thought about what may be happening here. PostgresNode.pm picks a random high port number and tests to see if it's free using pg_isready, with (unless I'm misreading) any non-zero result code being taken as "it's free". The problem here is that that completely fails to recognize a port being used by a non-Postgres process as not-free --- most likely, you'll get PQPING_NO_RESPONSE for that case. 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. I think we should forget about pg_isready altogether here, and instead write some code that either tries to bind() the target port number itself, or tries a low-level TCP connection request to the target port. I'm not sure what's the most convenient way to accomplish either in Perl. The bind() solution would provide a more trustworthy answer, but it might actually create more problems than it solves if the OS requires a cooling-off period before giving the port out to a different process. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
