On 04/18/2018 07:22 AM, Tom Lane wrote:
Pavel Raiskup <praiskup@xxxxxxxxxx> 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@xxxxxxxxxxx
