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