Re: pg_postmaster_reload_time() patch

On Wed, Apr 30, 2008 at 12:58 PM, George Gensure <werkt0@gmail.com> wrote:
> On Wed, Apr 30, 2008 at 8:16 AM, Alvaro Herrera
>  <alvherre@commandprompt.com> wrote:
>
>
> > George Gensure escribió:
>  >
>  >
>  > > I've done a quick write up for reload time reporting from the
>  >  > administration TODO.  I was a little paranoid with the locking, but
>  >  > didn't want problems to occur with signals on the postmaster and the
>  >  > read side.
>  >
>  >  I'd say too much -- postmaster runs with signals blocked all the time
>  >  (except during select()) so this is not necessary there.
>  >
>  >  Regarding the locking on backends, I admit I am not sure if this is
>  >  really a problem enough that you need a spinlock for it.  Anyway we tend
>  >  not to use spinlocks too much -- probably an LWLock would be more
>  >  apropos, if a lock is really needed.  (A bigger question is whether the
>  >  reload time should be local for each backend, or exposed globally
>  >  through MyProc.  I don't think it's interesting enough to warrant that,
>  >  but perhaps others think differently.)
>  >
>  >  Lastly, I didn't read the patch close enough to tell if it would work on
>  >  both the EXEC_BACKEND case and the regular one.
>  >
>  >  --
>  >  Alvaro Herrera                                http://www.CommandPrompt.com/
>  >  The PostgreSQL Company - Command Prompt, Inc.
>  >
>
>  I've reworked the patch in response to comments.
>
>  The new function name is pg_conf_load_time()
>  I'm now using LWLocks only on the backend in order to protect the
>  PgReloadTime from mid copy reads.  This may prove to be unnecessary,
>  since the code to handle HUPs seems to be executed synchronously on
>  the backend, but I'll let someone else tell me its safe before
>  removing it.
>
>  -George
>

So if nobody's got any further objections, could this patch be applied?

-George