On Wed, Oct 26, 2016 at 8:41 AM, Kuntal Ghosh <kuntalghosh.2...@gmail.com> wrote: > On Wed, Oct 26, 2016 at 4:47 PM, Michael Paquier > <michael.paqu...@gmail.com> wrote: >> >> If you test on a master node that would be the same: there is a delay >> until the stats process restart. I have not looked at the code closely >> enough in this area (reaper()?) to determine if there are ways to >> improve the responsiveness of this process restart that is a >> non-auxiliary proces btw, still improving this behavior is something I >> feel would be invasive, and something that would be dedicated to HEAD. >> The patch proposed here by Tsunakawa-san makes at least sure that a >> node in PM_HOT_STANDBY state restarts it. > Yes, you are right. Master also has some delay for restarting the > process. Otherwise, the patch solves the problem.
The delay is intentional. Per pgstat_start(): /* * Do nothing if too soon since last collector start. This is a safety * valve to protect against continuous respawn attempts if the collector * is dying immediately at launch. Note that since we will be re-called * from the postmaster main loop, we will get another chance later. */ curtime = time(NULL); if ((unsigned int) (curtime - last_pgstat_start_time) < (unsigned int) PGSTAT_RESTART_INTERVAL) return 0; last_pgstat_start_time = curtime; Committed and back-patched all the way. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers