Re: contrib/pg_stat_statements 1226

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Alex Hunsaker" <badalex(at)gmail(dot)com>, "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: contrib/pg_stat_statements 1226
Date: 2009-01-02 02:59:04
Message-ID: 18013.1230865144@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Hunsaker 2009-01-02 03:05:00 Re: contrib/pg_stat_statements 1226
Previous Message Alex Hunsaker 2009-01-02 02:45:43 Re: contrib/pg_stat_statements 1226