Re: BUG #15382: Error create dictionary in pg_dump

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: mr(dot)kovalchuk(dot)andrey(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15382: Error create dictionary in pg_dump
Date: 2018-09-13 17:30:04
Message-ID: 11550.1536859804@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

=?utf-8?q?PG_Bug_reporting_form?= <noreply(at)postgresql(dot)org> writes:
> Dump is creates, but have one trouble. Result of using pg_resote command:

> pg_restore: [архиватор (БД)] could not execute query: ОШИБКА (Error):
> словарь текстового поиска (text search dictionary) "ispell_apteka25" не
> существует (not exists)
> Выполнялась команда (running command): CREATE TEXT SEARCH DICTIONARY
> "public"."thesaurus_apteka25" (
> TEMPLATE = "pg_catalog"."thesaurus",
> dictfile = 'apteka25', dictionary = 'ispell_apteka25' );

Yeah, this is a consequence of the security changes we made awhile back
to run dump and restore under restrictive search_path settings. You need
to explicitly schema-qualify that sub-dictionary name, since it isn't in
the pg_catalog schema. Unfortunately, since dictionary parameters are
just strings without a lot of fixed semantics to them, pg_dump can't
really fix this for you --- it doesn't know that that parameter refers
to a database object, or which database object.

> If i change argument dictionary for this note to: dictionary =
> 'public.ispell_apteka25' - it's now ok!

Yup, that's what you have to do. Note that this is a good thing
anyway, independently of pg_dump, because your old definition could
have failed if the thesaurus dictionary were invoked by any
application running under a nondefault search_path.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2018-09-13 17:42:10 Re: PostgreSQL 10.0 SELECT LIMIT performance problem
Previous Message Dilip Kumar 2018-09-13 15:12:33 Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query