Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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".

			regards, tom lane

In response to


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group