From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
---|---|
To: | Alex Ignatov <a(dot)ignatov(at)postgrespro(dot)ru> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Ivan Kartyshov <i(dot)kartyshov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: long transactions on hot standby feedback replica / proof of concept |
Date: | 2017-09-04 16:06:55 |
Message-ID: | CAPpHfdsdzAcChn8tJLbPGvGK43=Sik4tETB0V0S0mTMZYk+gJw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 4, 2017 at 4:51 PM, Alex Ignatov <a(dot)ignatov(at)postgrespro(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2017-09-04 16:16:00 | Re: ALTER INDEX .. SET STATISTICS ... behaviour |
Previous Message | David Fetter | 2017-09-04 15:20:58 | Re: GnuTLS support |