Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept
| От | Alexander Korotkov |
|---|---|
| Тема | Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept |
| Дата | |
| Msg-id | CAPpHfdsdzAcChn8tJLbPGvGK43=Sik4tETB0V0S0mTMZYk+gJw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept ("Alex Ignatov" <a.ignatov@postgrespro.ru>) |
| Ответы |
Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept
|
| Список | 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.
The Russian Postgres Company
В списке pgsql-hackers по дате отправления: