Re: Pg_upgrade error could not load library from 7.14/8.4 to 10.10version
От | Ekaterina Amez |
---|---|
Тема | Re: Pg_upgrade error could not load library from 7.14/8.4 to 10.10version |
Дата | |
Msg-id | b357dd47-0350-8cc8-0d0d-d4dce4446ca1@zunibal.com обсуждение исходный текст |
Ответ на | Re: Pg_upgrade error could not load library from 7.14/8.4 to 10.10version (Achilleas Mantzios <achill@matrix.gatewaynet.com>) |
Ответы |
Re: Pg_upgrade error could not load library from 7.14/8.4 to 10.10version
|
Список | pgsql-admin |
Hi Achilleas, El 20/9/19 a las 9:26, Achilleas Mantzios escribió: > Just tested in my 11 and 10 : > dynacom=# select proname,probin,pronamespace from pg_proc where > proname='plpgsql_call_handler'; > proname | probin | pronamespace > ----------------------+---------------------------------+-------------- > plpgsql_call_handler | $libdir/plpgsql | 11 > plpgsql_call_handler | /usr/local/pgsql/lib/plpgsql.so | 2200 > (2 rows) > > with 2200 being the public namespace/schema. > > I my case, in every postgresql installation since 2001, always libdir > was /usr/local/pgsql/lib/ , so maybe this problem could not be > manifested. Did you check to see if you have the plpgsql_call_handler > defined in two schemas as well? > > -- > Achilleas Mantzios > IT DEV Lead > IT DEPT > Dynacom Tankers Mgmt I've restored template1 in v8.4, and created again the db where I will be restoring v7.14 backup newdb=# select proname,probin,pronamespace from pg_proc where proname='plpgsql_call_handler'; proname | probin | pronamespace ---------+--------+-------------- (0 filas) And in v10.10 (which is still an empty installation) template1=# select proname,probin,pronamespace from pg_proc where proname='plpgsql_call_handler'; proname | probin | pronamespace ----------------------+-----------------+-------------- plpgsql_call_handler | $libdir/plpgsql | 11 (1 row) After restoring backup in v8.4: newdb=# select proname,probin,pronamespace from pg_proc where proname='plpgsql_call_handler'; proname | probin | pronamespace ----------------------+----------------------------------------+-------------- plpgsql_call_handler | $libdir/plpgsql | 11 plpgsql_call_handler | /usr/lib/postgresql/8.4/lib/plpgsql.so | 2200 (2 filas) As you said, 2200 is public namespace/schema and 11 is pg_catalog. At the beginning of the backup file I can find these sentences: CREATE FUNCTION plpgsql_call_handler() RETURNS language_handler LANGUAGE c AS '/usr/lib/postgresql/8.4/lib/plpgsql.so', 'plpgsql_call_handler'; <-- I've changed this line to use the right path to plpgsql.so library CREATE PROCEDURAL LANGUAGE plpgsql HANDLER plpgsql_call_handler; I guess these are the ones causing all of this. **What should be the best way to handle this situation?** Remove these lines and create the language explicitly when creating database? Or replace them with a create language sentence? Maybe something else? My final goal is migrate from 7.14 server to 8.4 server and after that (if I have an OK from the boss) upgrade 8.4 to the latest version that I can use. Server uses CentOS, and probably I won't be able to upgrade to v10 but I hope at least 9.5/9.6 will be available.
В списке pgsql-admin по дате отправления: