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

Reply via email to