Re: Sudden FTS-related error from parallel worker in 9.6

On Tue, Oct 4, 2016 at 8:37 AM, Devrim G=C3=BCnd=C3=BCz <devrim@gunduz.org>=
 wrote:
>
>
> I am not 100% familiar with this, but IIRC you need to create this in tha=
t
> database, too.
>

No I don't. I'm not using FTS in that database.
I undertand that setting this FTS option cluster-wide might be not a good
solution, but nobody prohibits doing so.



>
> I first created the tables as you did, and then:
>
> postgres=3D# SELECT version();
>                                                  version
> ------------------------------------------------------------
> ---------------------------------------------
>  PostgreSQL 9.6.0 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 6.2.1
> 20160916 (Red Hat 6.2.1-2), 64-bit
> (1 row)
>
> postgres=3D# CREATE TEXT SEARCH CONFIGURATION ru (COPY=3Drussian);
> CREATE TEXT SEARCH CONFIGURATION
> postgres=3D# EXPLAIN ANALYZE SELECT min(ts) FROM test;
>                                                    QUERY PLAN
> ------------------------------------------------------------
> -----------------------------------------------------
>  Aggregate  (cost=3D2266.00..2266.01 rows=3D1 width=3D8) (actual
> time=3D15.740..15.740 rows=3D1 loops=3D1)
>    ->  Seq Scan on test  (cost=3D0.00..2016.00 rows=3D100000 width=3D8) (=
actual
> time=3D0.006..8.032 rows=3D100000 loops=3D1)
>  Planning time: 0.212 ms
>  Execution time: 15.782 ms
> (4 rows)
>
> postgres=3D# SET default_text_search_config TO ru;
> SET
> postgres=3D# EXPLAIN ANALYZE SELECT min(ts) FROM test;
>                                                    QUERY PLAN
> ------------------------------------------------------------
> -----------------------------------------------------
>  Aggregate  (cost=3D2266.00..2266.01 rows=3D1 width=3D8) (actual
> time=3D13.292..13.293 rows=3D1 loops=3D1)
>    ->  Seq Scan on test  (cost=3D0.00..2016.00 rows=3D100000 width=3D8) (=
actual
> time=3D0.009..6.572 rows=3D100000 loops=3D1)
>  Planning time: 0.069 ms
>  Execution time: 13.317 ms
> (4 rows)


> postgres=3D# SET max_parallel_workers_per_gather TO 8;
> SET
> postgres=3D# EXPLAIN ANALYZE SELECT min(ts) FROM test;
>                                                    QUERY PLAN
> ------------------------------------------------------------
> -----------------------------------------------------
>  Aggregate  (cost=3D2266.00..2266.01 rows=3D1 width=3D8) (actual
> time=3D13.701..13.701 rows=3D1 loops=3D1)
>    ->  Seq Scan on test  (cost=3D0.00..2016.00 rows=3D100000 width=3D8) (=
actual
> time=3D0.009..6.882 rows=3D100000 loops=3D1)
>  Planning time: 0.063 ms
>  Execution time: 13.722 ms
> (4 rows)
>

In your case parallel execution didn't happen. Try
setting force_parallel_mode to on, for testing purposes.
Also, to repeat my case, you need to try running this query in 'test'
database, where 'ru' configuration doesn't exist.


>
> postgres=3D# \c test
> You are now connected to database "test" as user "postgres".
> test=3D# SET default_text_search_config TO ru;
> ERROR:  invalid value for parameter "default_text_search_config": "ru"
>

It's ok and runs like expected. But it by no means relates to my case,
where the query wasn't meant to be touching FTS stuff.