Thread: invalid value for parameter "default_text_search_config": "public.pg"

I try to execute this on a very simple table, in a production database:

On 7/20/23 22:25, Les wrote:
> I try to execute this on a very simple table, in a production database:
> 
> alter table product.product add proc_order int8;
> create index idx_product_proc_order_status on product.product(proc_order 
> nulls last, product_status_id /* this has type uuid */ );
> 
> and I get this error:
> 
> SQL Error [22023]: ERROR: invalid value for parameter 
> "default_text_search_config": "public.pg <http://public.pg>"
>    Where: while setting parameter "default_text_search_config" to 
> "public.pg <http://public.pg>" parallel worker

What client are you using to run the commands?

> 
> I have been using this database for many weeks now, and never got a 
> similar message. I don't understand how the creation of an index on an 
> int8 and an uuid field is related to full text search.
> 
> Thanks,
> 
>      Laszlo
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com

On 7/21/23 08:14, Les wrote:

Please reply to list also.
Ccing list to get reply back on list.

> First I got this error when using a custom python program with asyncpg 
> driver. https://magicstack.github.io/asyncpg/current/ 
> <https://magicstack.github.io/asyncpg/current/>
> 
> Then I tried the "CREATE INDEX" command from Dbeaver (which uses JDBC) 
> and I got the same error.
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com

Les <nagylzs@gmail.com> writes:
> I found out that "public.pg" is not a valid configuration indeed.

Quite so (and even more so given that the actual setting seems to be
"public.pg <http://public.pg>").

> But I still don't know how it affects a query that does not use any
> tsvector or tsquery.

The error report shows that the failure is happening while starting
a parallel worker, so the only thing required of your query is that
it be big enough to tempt the planner to use parallelism.

However, the parallel worker should just be absorbing the same
configuration settings your main session is using.  So what remains
to be explained is why you aren't seeing the same complaint when
starting a fresh session.  It might be useful to look at the
output of

show default_text_search_config;

and

select * from pg_file_settings where name = 'default_text_search_config';

            regards, tom lane

Les <nagylzs@gmail.com> writes:
> mydatabase=# select * from pg_file_settings where name =
> 'default_text_search_config';
>                  sourcefile                 | sourceline | seqno |
>    name                    |  setting  | applied |            error
>
--------------------------------------------+------------+-------+----------------------------+-----------+---------+------------------------------
>  /opt/postgresql/data/conf.d/06_locale.conf |         17 |    24 |
> default_text_search_config | public.pg | f       | setting could not be applied
> (1 row)

> I'm not sure what applied="public.pg", error="setting could not be applied"
> means.

No, "applied" is "f" (false), meaning that the setting is not actually usable.
I'm a little surprised that it seems to have gotten into your live session
anyway, although perhaps that's because the postmaster can't really
validate it at startup.

> I can change it in the config file, no problem. I just would like to
> know if this is a simple configuration error, or a software installation
> error. (Is public.pg a built-in config that should always exist?)

"public.pg" is certainly not a standard (as in built-in) text search
configuration name.  Maybe that value was installed by some bit of
software that failed to install the configuration to go with it,
or only put the configuration into one database not everywhere in
your installation?

            regards, tom lane