Noah Misch <noah@leadboat.com> writes:
> I reproduced narwhal's problem using its toolchain on another 32-bit Windows
> Server 2003 system. The crash happens at the SHGetFolderPath() call in
> pqGetHomeDirectory(). A program can acquire that function via shfolder.dll or
> via shell32.dll; we've used the former method since commit 889f038, for better
> compatibility[1] with Windows NT 4.0. On this system, shfolder.dll's version
> loads and unloads shell32.dll. In PostgreSQL built using this older compiler,
> shfolder.dll:SHGetFolderPath() unloads libpq in addition to unloading shell32!
> That started with commit 846e91e.
Thanks for doing the detective work on this!
> I don't expect to understand the mechanism
> behind it, but I recommend we switch back to linking libpq with shell32.dll.
> The MSVC build already does that in all supported branches, and it feels right
> for the MinGW build to follow suit in 9.4+. Windows versions that lack the
> symbol in shell32.dll are now ancient history.
This is basically reverting 889f038, right? It looks to me like we made
that change only to support NT4, which was obsolete even in 2005, so no
objection from me. Magnus might have a different idea though.
> I happened to try the same contrib/dblink test suite on PostgreSQL built with
> modern MinGW-w64 (i686-4.9.1-release-win32-dwarf-rt_v3-rev1). That, too, gave
> a crash-like symptom starting with commit 846e91e.
Ick.
> Passing -static-libgcc to the link restores the libgcc situation as it stood
> before commit 846e91e. The main beneficiary of shared libgcc is C++/Java
> exception handling, so PostgreSQL doesn't care. No doubt there's some deeper
> bug in libgcc or in PostgreSQL; loading a module that links with shared libgcc
> should not disrupt exit(). I'm content with this workaround.
Works for me too, until such time as somebody feels like digging deeper.
regards, tom lane