Re: pg_upgade vs config - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: pg_upgade vs config
Date
Msg-id a4ec98ca-6f4e-dc18-8237-adf4ad8681e2@dunslane.net
Whole thread Raw
In response to Re: pg_upgade vs config  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_upgade vs config  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On 10/02/2016 12:54 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> The biggest issue is this: the upgrade fails completely on
>> ltree-plpython and hstore-plpython, presumably because these modules
>> rely on the plpython module being loaded first. pg_upgrade rather
>> simple-mindedly calls LOAD on the object library to test if it's usable.
> FWIW, that seems to have worked fine yesterday on prairiedog.
>
> I suspect the explanation is that macOS's dynamic linker is smart enough
> to pull in plpython when one of those modules is LOAD'ed.  The ideal fix
> would be to make that happen on all platforms.  I'm not actually sure
> why it doesn't already; surely every dynamic linker in existence has
> such a capability.
>
> [ digs more deeply ... ]  Oh, weird: it looks like this succeeded in
> every case except 9.6->HEAD upgrade.  Did we break something recently?


Yeah, my latest version of the test module (soon to hit githyb) also 
does a self upgrade, and these modules pass that on 9.5, whereas they 
fail on 9.6, as well as the 9.6->HEAD and HEAD self-tests failing. So 
indeed it looks like we've broken something. Yet another example of why 
I need to get this test module production ready :-)

cheers

andrew




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_upgade vs config
Next
From: Christoph Berg
Date:
Subject: Non-empty default log_line_prefix