On Mon, Sep 4, 2017 at 4:51 PM, Alex Ignatov <a.igna...@postgrespro.ru> wrote:
> In this situation this parameter (max_standby_streaming_delay) wont help > because if you have subsequent statement on standby (following info is from > documentation and from our experience ): Thus, if one query has resulted in > significant delay, subsequent conflicting queries will have much less grace > time until the standby server has caught up again. And you never now how to > set this parameter exept to -1 which mean up to infinity delayed standby. > > On our experience only autovacuum on master took AccesExclusiveLock that > raise this Fatal message on standby. After this AccessExclusive reached > standby and max_standby_streaming_delay > -1 you definitely sooner or > later get this Fatal on recovery . > With this patch we try to get rid of AccessEclusiveLock applied on standby > while we have active statement on it. > +1, Aborting read-only query on standby because of vacuum on master seems to be rather unexpected behaviour for user when hot standby feedback is on. I think we should work on this problem for v11. Backpatching documentation for previous releases would be good too. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
