Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept
Date
Msg-id CAPpHfdsdzAcChn8tJLbPGvGK43=Sik4tETB0V0S0mTMZYk+gJw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept  ("Alex Ignatov" <a.ignatov@postgrespro.ru>)
Responses Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
On Mon, Sep 4, 2017 at 4:51 PM, Alex Ignatov <a.ignatov@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 

pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: [HACKERS] GnuTLS support
Next
From: Alexander Korotkov
Date:
Subject: Re: [HACKERS] ALTER INDEX .. SET STATISTICS ... behaviour