Re: Removing dependency to wsock32.lib when compiling code on WIndows

From: Noah Misch <noah(at)leadboat(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, MauMau <maumau307(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Removing dependency to wsock32.lib when compiling code on WIndows
Date: 2014-08-29 14:15:47
Message-ID: 20140829141547.GA816991@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 21, 2014 at 11:29:31PM -0400, Noah Misch wrote:
> On Thu, Aug 21, 2014 at 09:18:22AM -0400, Andrew Dunstan wrote:
> > What's happening about this? Buildfarm animal jacana is consistently
> > red because of this.
>
> If nobody plans to do the aforementioned analysis in the next 4-7 days, I
> suggest we adopt one of Michael's suggestions: force "configure" to reach its
> old conclusion about getaddrinfo() on Windows. Then the analysis can proceed
> on an unhurried schedule.

Done.

Incidentally, jacana takes an exorbitant amount of time, most recently 87
minutes, to complete the ecpg-check step. Frogmouth takes 4 minutes, and none
of the other steps have such a large multiplier between the two animals. That
pattern isn't new and appears on multiple branches. I wonder if ecpg tickles
a performance bug in 64-bit MinGW-w64.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-08-29 14:15:55 Re: Misleading error message in logical decoding for binary plugins
Previous Message Tom Lane 2014-08-29 14:12:34 Re: 9.5: Better memory accounting, towards memory-bounded HashAgg