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.
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 |