On Thu, Jan 1, 2009 at 19:59, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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".
Cool! Err interesting...
> http://archives.postgresql.org/pgsql-committers/2009-01/msg00008.php
Yeah I saw your commits just shortly after hitting send on my reply :)
