On Wed, Apr 30, 2008 at 12:58 PM, George Gensure <[EMAIL PROTECTED]> wrote: > On Wed, Apr 30, 2008 at 8:16 AM, Alvaro Herrera > <[EMAIL PROTECTED]> 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 -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
