Adrian Klaver <adrian.klaver@aklaver.com> writes:
> On 04/18/2018 07:22 AM, Tom Lane wrote:
>
>> Pavel Raiskup <praiskup@redhat.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.consulting@comcast.net
p: 312.241.7800
