I wrote:
> The WARNING seems to indicate that the error check in set_config_option
> is too aggressive. I kind of wonder why it was placed there at all,
> rather than in SQL-level operations like ExecSetVariableStmt.
BTW, looking back at the thread, nobody seems to have posted an analysis
of why this happens, but it's pretty simple. During initial library load
of plperl.so, that module does DefineCustomStringVariable. If there is
a pre-existing reset_val of the variable (taken from the postgresql.conf
file, in this example), then define_custom_variable uses set_config_option
to apply that value to the newly created variable struct. So if plperl
library load happens during a parallel operation, the IsInParallelMode
check in set_config_option will bleat about it.
That test is, therefore, wrong. Otherwise, no non-builtin function
could ever be marked parallel safe, for fear that the shlib it lives
in might try to set up a custom variable at load time.
I'm of the opinion that having such a test here at all is crummy design.
It implies that set_config_option is in charge of knowing about every
one of its callers and passing judgment on whether they represent
parallel-safe usages, which is the exact opposite of modularity,
even if set_config_option had enough information to make that judgment
which it does not.
In any case, the parallel index build patch is not at fault, it just
happens to be involved in this particular example. I'd put the blame
on commit 924bcf4f1 which installed this test in the first place.
regards, tom lane