Re: contrib/pg_stat_statements 1226 - Mailing list pgsql-hackers

From Alex Hunsaker
Subject Re: contrib/pg_stat_statements 1226
Date
Msg-id 34d269d40901031200p71b7974en25abb85faab5acfc@mail.gmail.com
Whole thread Raw
In response to Re: contrib/pg_stat_statements 1226  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Jan 2, 2009 at 20:20, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> * 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.
>
> OK, I figured out what is happening there: the patch makes it work by
> means of this expedient:

<snip>

> I find this mighty Rube Goldbergian.  We have a startup hook which is
> declared in include/storage/ipc.h, but defined and called in bootstrap.c
> (whence it will actually be executed down inside the startup process).
> We have a shutdown hook which is also declared in include/storage/ipc.h,
> but defined and called in bgwriter.c (executed in the bgwriter process,
> of course).  And to make those hooks work in the EXEC_BACKEND case, we
> have a kluge inserted in proc.c, miles away from where the existing
> process_shared_preload_libraries() calls are (in postmaster.c), and with
> extremely high probability of someday resulting in duplicate preload
> operations if the postmaster.c code gets shuffled.

Kudos to Itagaki-san for getting that to work?

> As for the shutdown hook, I don't think we need it at all in this
> design.  When loaded into the postmaster process, pg_stat_statements can
> insert itself into the on_proc_exit or on_shmem_exit hook lists ... it
> doesn't need a private hook.

Ok cool.

> The right way to make that happen is to rearrange the coding in
> SubPostmasterMain() so that process_shared_preload_libraries is
> done in all cases, just after the read_nondefault_variables call.

This should also fix the rmg hooks patch on EXEC_BACKEND.


pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: [BUGS] BUG #4599: bugfix for contrib/dblink module
Next
From: Tom Lane
Date:
Subject: Re: Custom PGC_POSTMASTER GUC variables ... feasible?