Re: "dumpProcLangs(): handler procedure for language

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: "dumpProcLangs(): handler procedure for language
Дата
Msg-id 22956.1039496530@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: "dumpProcLangs(): handler procedure for language  (Brian Fujito <brian@lightsource.com>)
Ответы Re: "dumpProcLangs(): handler procedure for language  ("Dan Langille" <dan@langille.org>)
Re: "dumpProcLangs(): handler procedure for language  (Brian Fujito <brian@lightsource.com>)
Список pgsql-admin
Brian Fujito <brian@lightsource.com> writes:
>> What exactly are you doing to drop and re-add the language?  I should
>> think CREATE LANGUAGE would fail if the handler proc isn't there.

> I've tried both ways:

> createlang/droplang from the command line as user postgres

> and:

> CREATE FUNCTION plpgsql_call_handler () RETURNS OPAQUE AS
>         '/usr/lib/pgsql/plpgsql.so' LANGUAGE 'C';

> CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql'
>         HANDLER plpgsql_call_handler
>           LANCOMPILER 'PL/pgSQL';

Hrmph.  Looks perfectly standard from here; I don't see why pg_dump is
failing to find the handler.  It would help to see what the server-side
view of the transaction is like.  Would you run pg_dump after setting
query logging on (from memory, I think export PGOPTIONS="-d2" will work
in 7.0, but too tired to check it) and then show us the tail end of the
postmaster log after pg_dump fails?

            regards, tom lane

PS: a wild-*ss guess: 7.0 wasn't too clean in handling OIDs above 2
billion; is it possible your pg_language OID for plpgsql is over 2G?

В списке pgsql-admin по дате отправления:

Предыдущее
От: Brian Fujito
Дата:
Сообщение: Re: "dumpProcLangs(): handler procedure for language
Следующее
От: "Dan Langille"
Дата:
Сообщение: Re: "dumpProcLangs(): handler procedure for language