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

On Mon, Oct 10, 2016 at 9:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
>> On Sat, Oct 8, 2016 at 11:13 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> 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.
>
> OK, I'd misunderstood the problem --- I supposed that the worker was
> getting the bad value directly from postgresql.conf, but I now see
> that that's not happening; the bad value is in place in the leader,
> and the worker is failing to accept it when it's passed over.
>
> This evidently goes back to the comment you made before:
>
>>> 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()).
>
> So I guess the question is why in the world are we doing that inside
> a transaction.
>

I think that is required for some of the parameters like
"session_authorization". If user has set this for leader backend and
we want it to be reflected in worker backend, then without starting
transaction it won't allow (refer check_session_authorization()).

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