On Wed, Oct 26, 2016 at 7:12 PM, Kuntal Ghosh <kuntalghosh.2...@gmail.com> wrote: > On Wed, Oct 26, 2016 at 12:10 PM, Michael Paquier > <michael.paqu...@gmail.com> wrote: >> On Wed, Oct 26, 2016 at 2:46 PM, Tsunakawa, Takayuki >> <tsunakawa.ta...@jp.fujitsu.com> wrote: >>> If the stats collector is forcibly terminated on the standby in streaming >>> replication configuration, it won't be restarted until 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
