Horton

Re: narwhal and PGDLLIMPORT

Noah Misch <noah@leadboat.com>

View thread
From: Noah Misch <noah@leadboat.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Dave Page <dpage@pgadmin.org>, Alvaro Herrera <alvherre@2ndquadrant.com>, Hiroshi Inoue <inoue@tpf.co.jp>, Andrew Dunstan <andrew@dunslane.net>, Craig Ringer <craig@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@2ndquadrant.com>, Amit Kapila <amit.kapila16@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2014-10-15T04:53:03Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. MinGW: Link with shell32.dll instead of shfolder.dll.

  2. Centralize getopt-related declarations in a new header file pg_getopt.h.

  3. Get rid of use of dlltool in Mingw builds.

  4. Export a few more symbols required for test_shm_mq module.

  5. Export set_latch_on_sigusr1 symbol for Windows.

  6. Use SHGetFolderPath instead of SHGetSpecialFolderPath to find the

On Tue, Oct 14, 2014 at 07:07:17PM -0400, Tom Lane wrote:
> Dave Page <dpage@pgadmin.org> writes:
> > On Tue, Oct 14, 2014 at 11:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> I think we're hoping that somebody will step up and investigate how
> >> narwhal's problem might be fixed.

I have planned to look at reproducing narwhal's problem once the dust settles
on orangutan, but I wouldn't mind if narwhal went away instead.

> > However, if "fixing" it comes down to upgrading the seriously old
> > compiler and toolchain on that box (which frankly is so obsolete, I
> > can't see why anyone would want to use anything like it these days),
> > then I think the best option is to retire it, and replace it with
> > Windows 2012R2 and a modern release of MinGW/Msys which is far more
> > likely to be similar to what someone would want to use at present.

If you upgrade the toolchain, you really have a new animal.

> No argument here.  I would kind of like to have more than zero
> understanding of *why* it's failing, just in case there's more to it
> than "oh, probably a bug in this old toolchain".  But finding that out
> might well take significant time, and in the end not tell us anything
> very useful.

Agreed on all those points.

> Is it likely that anyone is still using Windows 2003 in the field?
> A possible compromise is to update the toolchain but stay on the
> same OS release, so that we still have testing that's relevant to
> people using older OS releases.

Windows Server 2003 isn't even EOL yet.  I'd welcome a buildfarm member with
that OS and a modern toolchain.