Re: pg_upgrade: when the --old-bindir requires "additional" $libdir/ plugins?

Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> writes:

> On 04/18/2018 07:22 AM, Tom Lane wrote:
>
>> Pavel Raiskup <praiskup(at)redhat(dot)com> writes:
>>> . and it seems like the hstore.so was somewhat intimately integrated into
>>> OP's database so the '/usr/bin/pg_dump --schema-only --binary-upgrade
>>> --format=custom' called through 'pg_upgrade' failed with:
>>> pg_dump: [archiver (db)] query failed: ERROR: could not access file
>>> "$libdir/hstore": No such file or directory
>>> Which means that the dump from old datadir, with old server (without
>>> hstore.so packaged) failed. But playing with hstore.so a bit, the upgrade
>>> always worked smoothly for me even without the "old" hstore.so
>>
>> Hi Pavel,
>>
>> There are certainly plenty of reasons why extension .so's might be needed
>> during pg_dump, even in a binary-upgrade situation. The first example
>> that comes to mind is that an hstore-type constant appearing in a view
>> definition would require hstore_out() to be invoked while dumping the view
>> definition.
>
> I am obviously missing something. If the old server was using hstore
> in a database how could hstore.so could be accessible to it but not
> pg_dump?

I presume because something stole the depended upon libs but went
unnoticed due to the referring objs being generally unused.

Along comes pg_upgrade and the requisite dump... BOOM!

>
>>
>> I don't remember anymore whether I'd set up the postgresql-update package
>> to include the contrib modules for the old server version. If I didn't,
>> it was an oversight :-(.
>>
>> regards, tom lane
>>
>>

--
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres(dot)consulting(at)comcast(dot)net
p: 312.241.7800