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

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. Seems like a waste of cycles as well as a cause of
inappropriate failures. Or in other words, my comment above still
holds, mutatis mutandis: the worker should absorb EXACTLY the settings
that prevail in the parent, even if they're nominally invalid.

regards, tom lane