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