On Thu, Jan 1, 2009 at 19:59, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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...
Yeah I saw your commits just shortly after hitting send on my reply :)
In response to
pgsql-hackers by date
|Next:||From: Greg Stark||Date: 2009-01-02 03:53:54|
|Subject: Re: posix_fadvise v22|
|Previous:||From: Tom Lane||Date: 2009-01-02 02:59:04|
|Subject: Re: contrib/pg_stat_statements 1226 |