Re: contrib/pg_stat_statements 1226

On Thu, Jan 1, 2009 at 17:28, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Alex Hunsaker" <badalex(at)gmail(dot)com> writes:
>> ... So Im going to mark it as
>> ready for commmiter.
>
> Has this patch been tested on Windows? (Or more generally, with EXEC_BACKEND?)

I was under the impression thats where Itagaki-san develops.You'll
note some other specific windows changes:

pgstat_track_activity_query_size gains PGDLLIMPORT
process_shared_preload_libraries()
also seems of intreset:
http://archives.postgresql.org/pgsql-hackers/2008-12/msg01416.php

varoius carriage returns in the patch...

I could be wrong though.

> The reason I ask is that eyeballing the code suggests a couple of major
> problems in that area:
>
> * the startup/shutdown hooks will be installed in the postmaster
> process, but the patch expects them to be executed in a child process.
> I think nothing will happen.

I dunno about this one, not very familiar with EXEC_BACKEND

> * 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.

I see 3 options:
- add a GUC_CUSTOM_REDEFINE flag

- ignore redefines of custom gucs

-change the define_custom_variable() to return a bool (or something)
true if it got added
false if it was already there

Seems to me we could probably just ignore any redefines of custom gucs
outright. Im not to worried about some other module picking the same
custom guc. And frankly the op should notice. Especially when they
go to add it to custom_variable_classes.