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

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


-- 
Adrian Klaver
adrian.klaver@aklaver.com