Re: pg_upgade vs config

On 2016-10-02 17:59:47 -0400, Tom Lane wrote:
> I've found that the Linux '-l:hstore.so' solution works on HPUX as well,
> at least to the extent of being able to run LOAD. However, it doesn't
> seem to be possible to make it work on macOS, which has a hard distinction
> between "loadable modules" and "shared libraries". Our extensions are
> the former, which means that e.g. hstore.so is not a shlib and the linker
> will refuse to consider it as a linkable library. I tried converting
> them to true shlibs, which is just a matter of changing "-bundle" to
> "-dynamiclib" in the link command and dropping "-bundle_loader postgres"
> because that's not accepted with "-dynamiclib". That works about 90%,
> but I found that plpython failed its regression test for a very scary
> reason: there's a "hash_search()" somewhere in libc on this platform
> and the linker was preferentially resolving plpython's call to that
> rather than to the one in Postgres. I don't think we want to risk
> that sort of platform dependency :-(

ISTM that that's a risk independent of this specific issue? On other
platforms, I mean?

> So now I'm thinking you're right, it'd be better to have some solution
> whereby dfmgr.c knows about cross-module dependencies and loads the
> dependencies first. Not sure how to approach that. The extension
> "requires" mechanism is tantalizingly close to providing the data
> we need, but dfmgr.c doesn't know about that, and there's no concept
> of a reverse mapping from .so names to extensions anyway.

One, kind of extreme, way to get there would be to resolve the hstore
symbols hstore_plpython needs with load_external_function, during
_PG_init(). Most of these files don't actually depend on a large number
of symbols, so that should actually be doable.

Greetings,

Andres Freund