Horton

Re: narwhal and PGDLLIMPORT

Andres Freund <andres@2ndquadrant.com>

View thread
From: Andres Freund <andres@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Dave Page <dpage@pgadmin.org>, Hiroshi Inoue <inoue@tpf.co.jp>, Andrew Dunstan <andrew@dunslane.net>, Craig Ringer <craig@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2014-02-17T15:26:46Z
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 2014-02-17 10:21:12 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-02-17 15:02:15 +0000, Dave Page wrote:
> >> On Mon, Feb 17, 2014 at 2:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >>> In 9.3, narwhal is *still* showing a PGDLLIMPORT-type failure that no
> >>> other Windows critter is unhappy about:
> 
> >> Well, as we know, Narwhal is really quite old now. I think I built it
> >> seven+ years ago. Is it really worth banging heads against walls to
> >> support something that noone in their right mind should be using for a
> >> build these days?
> 
> > The problem is that lots of those issues are bugs that actually cause
> > problems for msvc builds. If there were tests in worker_spi it'd quite
> > possibly crash when run in 9.3. The problem is rather that the other
> > animals are *not* erroring.
> 
> Exactly.
> 
> Although on second thought, the lack of complaints from other Windows
> animals can probably be blamed on the fact that we didn't back-port
> any of the recent hacking on the Windows build processes.  Maybe we
> should think about doing so, now that the dust seems to have settled.

Yea, at the very least the gendef.pl thing should be backported,
possibly the mingw --disable-auto-import thing as well. But it's
probably a gooid idea to wait till the branches are stamped?

> We still need to know why narwhal is crashing on dblink though.
> I have a bad feeling that that may indicate still-unresolved
> linkage problems.

It's odd:

[53019d05.f58:2] LOG:  server process (PID 2428) exited with exit code 128
[53019d05.f58:3] DETAIL:  Failed process was running: SELECT *
	FROM dblink('dbname=contrib_regression','SELECT * FROM foo') AS t(a int, b text, c text[])
	WHERE t.a > 7;
[53019d05.f58:4] LOG:  server process (PID 2428) exited with exit code 0
[53019d05.f58:5] LOG:  terminating any other active server processes
[53019d06.e9c:2] WARNING:  terminating connection because of crash of another server process
[53019d06.e9c:3] DETAIL:  The postmaster has commanded this server process to roll back the curreGreetings,

Not sure if that's actually a segfault and not something else. Why is
the same death reported twice? With different exit codes?

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services