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

Re: contrib/pg_stat_statements 1226

From: "Alex Hunsaker" <badalex(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "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 03:05:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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 StarkDate: 2009-01-02 03:53:54
Subject: Re: posix_fadvise v22
Previous:From: Tom LaneDate: 2009-01-02 02:59:04
Subject: Re: contrib/pg_stat_statements 1226

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