Re: [HACKERS] Create language syntax is not proper in pg_dumpall andnot working using pg_upgrade

Поиск
Список
Период
Сортировка
От Thom Brown
Тема Re: [HACKERS] Create language syntax is not proper in pg_dumpall andnot working using pg_upgrade
Дата
Msg-id CAA-aLv42CtkJizVgtxEx17xn1Oh86vCXjrAjhjP39kj-kONJWQ@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] Create language syntax is not proper in pg_dumpall and not workingusing pg_upgrade  (tushar <tushar.ahuja@enterprisedb.com>)
Список pgsql-hackers
On 25 July 2017 at 12:09, tushar <tushar.ahuja@enterprisedb.com> wrote:
> v9.6
>
> postgres=# CREATE LANGUAGE alt_lang1 HANDLER plpgsql_call_handler;
> CREATE LANGUAGE
> postgres=# \q
>
> v10 , run pg_upgrade - failing with this error -
>
> pg_restore: creating pg_largeobject_metadata "pg_largeobject_metadata"
> pg_restore: creating COMMENT "postgres"
> pg_restore: creating SCHEMA "public"
> pg_restore: creating COMMENT "SCHEMA "public""
> pg_restore: creating PROCEDURAL LANGUAGE "alt_lang1"
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_restore: [archiver (db)] Error from TOC entry 560; 2612 16384 PROCEDURAL
> LANGUAGE alt_lang1 edb
> pg_restore: [archiver (db)] could not execute query: ERROR: unsupported
> language "alt_lang1"
> HINT:  The supported languages are listed in the pg_pltemplate system
> catalog.
>     Command was: CREATE OR REPLACE PROCEDURAL LANGUAGE "alt_lang1";
>
>
> take the cluster dump using pg_dumpall
> "
> --
> -- Name: alt_lang1; Type: PROCEDURAL LANGUAGE; Schema: -; Owner: edb
> --
>
> CREATE OR REPLACE PROCEDURAL LANGUAGE alt_lang1;
>
>
> ALTER PROCEDURAL LANGUAGE alt_lang1 OWNER TO edb;
> "
>
> Handler part is missing and due to that  it is throwing an error ,if we try
> to execute on psql terminal.

I think this is because the handler function is in the pg_catalog
schema, which aren't dumped.  However, it seems they need to be if a
non-pg_catalog language is created that uses them.

This seems odd though:

/* Skip if not to be dumped */
if (!plang->dobj.dump || dopt->dataOnly)       return;

...

funcInfo = findFuncByOid(plang->lanplcallfoid);
if (funcInfo != NULL && !funcInfo->dobj.dump && plang->dobj.dump)       funcInfo = NULL;                /* treat
not-dumpedsame as not-found */
 


The reason I think it's odd is because, if it finds that the language
needs to be dumped, it checks whether the functions referenced for the
handler, inline and validator are in the pg_catalog schema too.  If
they are, it doesn't output them, but if we know the language isn't in
pg_catalog, and the functions for these options are, then surely we
*have* to output them?  Should there be any checks for these functions
at all?

Thom



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

Предыдущее
От: Rajkumar Raghuwanshi
Дата:
Сообщение: Re: [HACKERS] UPDATE of partition key
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] pl/perl extension fails on Windows