Re: [HACKERS] pg_upgade vs config

On 10/02/2016 07:21 PM, Tom Lane wrote: I wrote: It occurs to me that a back-patchable workaround for this would be to make get_loadable_libraries sort the library names in order by length (and I guess we might as well sort same-length names alphabetically). This would for example guarantee

Re: [HACKERS] pg_upgade vs config

I wrote: > It occurs to me that a back-patchable workaround for this would be to > make get_loadable_libraries sort the library names in order by length > (and I guess we might as well sort same-length names alphabetically). > This would for example guarantee that hstore_plpython is probed after >

Re: [HACKERS] pg_upgade vs config

Andres Freund writes: > On 2016-10-02 17:59:47 -0400, Tom Lane wrote: >> 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

Re: [HACKERS] 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

Re: [HACKERS] pg_upgade vs config

I wrote: > So it doesn't seem that we've broken anything since 9.5 --- it didn't > work before either. The seeming successes may have been due to chance, > i.e. pg_upgrade probing the libraries in an order that happened to work. > I see no evidence that

Re: [HACKERS] pg_upgade vs config

Andrew Dunstan writes: > On 10/02/2016 12:54 PM, Tom Lane wrote: >> [ 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

Re: [HACKERS] pg_upgade vs config

On 10/02/2016 12:54 PM, Tom Lane wrote: Andrew Dunstan 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

Re: [HACKERS] pg_upgade vs config

Andrew Dunstan writes: > On 10/02/2016 01:53 PM, Tom Lane wrote: >> Because pg_dump with --binary-upgrade neglects to emit >> ALTER EXTENSION bloom ADD ACCESS METHOD bloom; >> which it would need to do in order to make this work right. The other >> small problem is that

Re: [HACKERS] pg_upgade vs config

On 10/02/2016 01:53 PM, Tom Lane wrote: So then why are the pre-upgrade and post-upgrade dumps different? Because pg_dump with --binary-upgrade neglects to emit ALTER EXTENSION bloom ADD ACCESS METHOD bloom; That's what I suspected. which it would need to do in order to make this work

Re: [HACKERS] pg_upgade vs config

Andrew Dunstan writes: > On 10/02/2016 09:50 AM, Michael Paquier wrote: >> On Sun, Oct 2, 2016 at 10:40 PM, Andrew Dunstan wrote: >>> It looks like we have some work to do to teach pg_dump about handling access >>> methods in extensions. This doesn't

Re: [HACKERS] pg_upgade vs config

I wrote: > 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

Re: [HACKERS] pg_upgade vs config

Andrew Dunstan 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

Re: [HACKERS] pg_upgade vs config

On 10/02/2016 09:50 AM, Michael Paquier wrote: On Sun, Oct 2, 2016 at 10:40 PM, Andrew Dunstan wrote: It looks like we have some work to do to teach pg_dump about handling access methods in extensions. This doesn't look quite as bad as the first issue, but it's a pity

Re: [HACKERS] pg_upgade vs config

On Sun, Oct 2, 2016 at 10:40 PM, Andrew Dunstan wrote: > It looks like we have some work to do to teach pg_dump about handling access > methods in extensions. This doesn't look quite as bad as the first issue, > but it's a pity 9.6 escaped into the wild with this issue.