Re: pg_postmaster_reload_time() patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "George Gensure" <werkt0(at)gmail(dot)com>
Cc: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: pg_postmaster_reload_time() patch
Date: 2008-05-04 21:23:33
Message-ID: 28779.1209936213@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

"George Gensure" <werkt0(at)gmail(dot)com> writes:
> The new function name is pg_conf_load_time()

Applied with revisions.

> 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.

The locking was not only entirely useless, but it didn't even compile,
since you'd not supplied a definition for "ReloadTimeLock". I took
it out.

I moved the setting of PgReloadTime into ProcessConfigFile.
The advantages are (1) only one place to do it, and (2) inside
ProcessConfigFile, we know whether or not the reload actually "took".
As committed, the definition of PgReloadTime is really "the time of
the last *successful* load of postgresql.conf", which I think is more
useful than "the last attempted load".

I also improved the documentation a bit and added the copy step needed
in restore_backend_variables().

regards, tom lane

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Brendan Jurd 2008-05-04 22:05:58 Re: [HACKERS] Multiline privileges in \z
Previous Message Andrew Dunstan 2008-05-04 17:55:29 Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout