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

On Sat, Oct 8, 2016 at 11:13 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
>> ... 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.
>
> The real problem here, I think, is that this report indicates that it's
> possible for a worker to try to execute a query with GUC settings
> different from its parent. Which means it could deliver results different
> than the parent would get. That's unacceptable.
>
> In Nikolay's report, we get an error because postgresql.conf contains
> an invalid value, but what if it had contained a valid value that was
> different from the parent session's? That's entirely legit, in case
> the file has been edited but the DBA hasn't yet issued SIGHUP.
>
> The mechanism needs to be fixed so that the worker absorbs EXACTLY the
> settings that prevail in the parent, no matter what is currently in
> postgresql.conf.
>

Hmm, currently the leader process serialize the guc values that
prevail before the launch of workers and then workers restore those
values (refer SerializeGUCState and RestoreGUCState). I am not sure
what makes you think that we are doing something else.

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