Adrian Klaver <adrian.klaver@xxxxxxxxxxx> writes: > 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 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@xxxxxxxxxxx p: 312.241.7800
