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

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.

            regards, tom lane