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.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to