On Wed, Apr 30, 2008 at 12:58 PM, George Gensure <werkt0@[EMAIL PROTECTED]
> wrote:
> On Wed, Apr 30, 2008 at 8:16 AM, Alvaro Herrera
> <alvherre@[EMAIL PROTECTED]
> wrote:
>
>
> > George Gensure escribi=F3:
> >
> >
> > > I've done a quick write up for reload time re****ting 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
t=
end
> > not to use spinlocks too much -- probably an LWLock would be more
> > apropos, if a lock is really needed. (A bigger question is whether
t=
he
> > reload time should be local for each backend, or exposed globally
> > through MyProc. I don't think it's interesting enough to warrant
tha=
t,
> > 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.CommandPromp=
t.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
--=20
Sent via pgsql-patches mailing list (pgsql-patches@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
|
