| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Pavel Raiskup <praiskup(at)redhat(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: pg_upgrade: when the --old-bindir requires "additional" $libdir/ plugins? |
| Date: | 2018-04-18 14:22:23 |
| Message-ID: | 29770.1524061343@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Pavel Raiskup <praiskup(at)redhat(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adrian Klaver | 2018-04-18 14:43:01 | Re: pg_upgrade: when the --old-bindir requires "additional" $libdir/ plugins? |
| Previous Message | Adrian Klaver | 2018-04-18 14:18:41 | Re: pg_upgrade: when the --old-bindir requires "additional" $libdir/ plugins? |