On Wed, Oct 26, 2016 at 7:12 PM, Kuntal Ghosh
<kuntalghosh.2007@gmail.com> wrote:
> On Wed, Oct 26, 2016 at 12:10 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Wed, Oct 26, 2016 at 2:46 PM, Tsunakawa, Takayuki
>> <tsunakawa.takay@jp.fujitsu.com> wrote:
>>> If the stats collector is forcibly terminated on the standby in streaming replication configuration, it won't be
restarteduntil the standby is promoted to the primary. The attached patch restarts the stats collector on the
standby.
>>>
>>> FYI, when the stats collector is down, SELECTs against the statistics views get stale data with the following
message.
>>>
>>> LOG: using stale statistics instead of current ones because stats collector is not responding
>>> STATEMENT: select * from pg_stat_user_tables
>>
>> Oops. This could be a problem for some applications... As far as I can
>> see and after playing with it, your patch looks correct.
>> --
> I've tested with the patch. The patch doesn't solve the problem
> completely. In standby, after forcible termination, statistics
> collector process is taking some time to get restarted. In between, if
> somebody SELECTs against the statistics views, he will still get stale
> data with the above LOG message.
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.
--
Michael
