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

On Sat, Oct 8, 2016 at 11:13 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapila16@gmail.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