Re: pg_upgrade: when the --old-bindir requires "additional" $libdir/ plugins?
От | Tom Lane |
---|---|
Тема | Re: pg_upgrade: when the --old-bindir requires "additional" $libdir/ plugins? |
Дата | |
Msg-id | 29770.1524061343@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | pg_upgrade: when the --old-bindir requires "additional" $libdir/ plugins? (Pavel Raiskup <praiskup@redhat.com>) |
Ответы |
Re: pg_upgrade: when the --old-bindir requires "additional" $libdir/plugins?
Re: pg_upgrade: when the --old-bindir requires "additional" $libdir/ plugins? |
Список | pgsql-general |
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 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
В списке pgsql-general по дате отправления: