I wrote:
> * in an EXEC_BACKEND situation, we re-execute
> process_shared_preload_libraries() when starting a fresh backend
> (but not in other kinds of child processes, which is why the other
> problem is a problem). This means re-executing the _PG_init function,
> which will try to redefine the custom GUC variables, which will fail.
> I don't think this is really a bug in this patch per se, it's a bug
> in the custom-GUC support; but nonetheless it looks like a problem.
Oh, never mind that part. I was thinking that the child process would
already know the real definition of the custom variable at the time it
tries to load the shared library, but actually the mechanism for pushing
GUC values into EXEC_BACKEND child processes doesn't transfer the whole
variable definition. It causes any such values to be loaded as
placeholders, and then the later load of the shared library converts the
placeholder to a regular variable. So it all works, or nearly anyway:
the code fails on a custom variable class whose name alphabetically
precedes "custom_variable_class".
http://archives.postgresql.org/pgsql-committers/2009-01/msg00008.php
regards, tom lane
