On Wednesday, April 18, 2018 4:43:01 PM CEST Adrian Klaver wrote: > 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? Because on Fedora we usually run pg_upgrade after distribution upgrade (e.g. for Fedora 27 => Fedora 28 upgrade it means also upgrade from PostgreSQL 9.6 to 10), and then we provide the old server in different package (postgresql-upgrade) which has limited feature set (including the missing hstore.so module). Pavel > > > > 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 > > > > > > >
