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