On Thu, Jan 1, 2009 at 19:59, Tom Lane <t...@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 :) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
