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

On Tue, Oct 4, 2016 at 9:03 AM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
> On 4 October 2016 at 13:38, Nikolay Samokhvalov <samokhvalov@gmail.com> wrote:
>> test=# explain analyze select min(ts) from test;
>>                                                        QUERY PLAN
>>
-------------------------------------------------------------------------------------------------------------------------
>>  Aggregate  (cost=226505.45..226505.46 rows=1 width=8) (actual
>> time=1460.227..1460.227 rows=1 loops=1)
>>    ->  Seq Scan on test  (cost=0.00..201504.76 rows=10000276 width=8)
>> (actual time=0.013..697.676 rows=10000000 loops=1)
>>  Planning time: 0.098 ms
>>  Execution time: 1460.257 ms
>> (4 rows)
>>
>> test=# set max_parallel_workers_per_gather to 8;
>> SET
>> test=#  explain analyze select min(ts) from test;
>> ERROR:  invalid value for parameter "default_text_search_config": "ru"
>> CONTEXT:  parallel worker
>
> The reason that you receive this message is that the main process must
> serialise all GUC settings into text before passing to the worker
> processes, and when the worker receive those serialised settings from
> the master, it must apply them so that workers behave the same way as
> the main process.
>
> Probably the question here is why is the worker process validating the
> GUC when it was not validated when postgresql.conf is loaded
>

The validation is done at postmaster startup time as well, but there
are few differences.  First is during postmaster startup, we are not
in any transaction whereas while restoring GUC's in worker we are in a
transaction, this error is mainly due to that reason (refer
check_TSCurrentConfig()).  Second difference is that during postmaster
start for this case (where source is PGC_S_FILE) we use elevel as
DEBUG3 or LOG depending on whether the process is under postmaster
where as in a worker, it is always ERROR.  So, I think here one
argument is that we can use error level other than ERROR during worker
startup, but not sure if that is improvement over current behaviour.
Certainly, if we are not able to restore any guc, it is better not to
proceed for execution in worker as I think that can lead to erroneous
results.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com