Subject: hot_standby_feedback and max_standby_archive_delay

From: Marko Tiikkaja <[email-masked]>
Date: Fri, 17 Jan 2014 00:38:13 +0100

Hi,

Myself and others found this statement in the documentation about 
$SUBJECT very confusing: "max_standby_archive_delay must be kept large 
in this case, because delayed WAL files might already contain entries 
that conflict with the desired standby queries.".  After a chat with 
Andres I've tried to make it clearer what said statement tries to convey.

Did I succeed?

Regards,
Marko Tiikkaja
*** a/doc/src/sgml/high-availability.sgml
--- b/doc/src/sgml/high-availability.sgml
***************
*** 1810,1818 **** if (!triggered)
      situation will be no worse than if the standby queries were running
      directly on the primary server, and you are still getting the benefit of
      off-loading execution onto the standby.
!     <varname>max_standby_archive_delay</> must be kept large in this case,
!     because delayed WAL files might already contain entries that conflict with
!     the desired standby queries.
     </para>
  
     <para>
--- 1810,1820 ----
      situation will be no worse than if the standby queries were running
      directly on the primary server, and you are still getting the benefit of
      off-loading execution onto the standby.
!     If a standby loses connectivity to the master, its
!     <varname>hot_standby_feedback</> value is not respected by the master until
!     the connection has been restored.  If the slave wishes to continue
!     executing queries in that case, its <varname>max_standby_archive_delay</>
!     should be kept large.
     </para>
  
     <para>

-- 
Sent via pgsql-docs mailing list ([email-masked])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

---

From: Fujii Masao <[email-masked]>
Date: Mon, 3 Feb 2014 01:08:44 +0900

On Fri, Jan 17, 2014 at 8:38 AM, Marko Tiikkaja <[email-masked]> wrote:
> Hi,
>
> Myself and others found this statement in the documentation about $SUBJECT
> very confusing: "max_standby_archive_delay must be kept large in this case,
> because delayed WAL files might already contain entries that conflict with
> the desired standby queries.".  After a chat with Andres I've tried to make
> it clearer what said statement tries to convey.
>
> Did I succeed?

Don't we need to increase also max_standby_streaming_delay
in the case that you mentioned in the patch? When the standby
successfully reconnects to the master, lots of WAL files would
be streamed and they might already have WAL entries that
conflict with standby queries. No?

Regards,

-- 
Fujii Masao

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 16 Apr 2014 14:51:15 -0400

> conflict with standby queries. No?

I have developed the attached doc patch to improve the wording on this
topic.

-- 
  Bruce Momjian  <[email-masked]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
new file mode 100644
index ecb51c4..39d7467
*** a/doc/src/sgml/high-availability.sgml
--- b/doc/src/sgml/high-availability.sgml
*************** if (!triggered)
*** 1889,1897 ****
      situation will be no worse than if the standby queries were running
      directly on the primary server, and you are still getting the benefit of
      off-loading execution onto the standby.
!     <varname>max_standby_archive_delay</> must be kept large in this case,
!     because delayed WAL files might already contain entries that conflict with
!     the desired standby queries.
     </para>
  
     <para>
--- 1889,1902 ----
      situation will be no worse than if the standby queries were running
      directly on the primary server, and you are still getting the benefit of
      off-loading execution onto the standby.
!     If standby servers connect and disconnect frequently, you
!     might want to make adjustments to handle the period when
!     <varname>hot_standby_feedback</> feedback is not being provided.
!     For example, consider increasing <varname>max_standby_archive_delay</>
!     so that queries are not rapidly cancelled by conflicts in WAL archive
!     files during disconnected periods.  You should also consider increasing
!     <varname>max_standby_streaming_delay</> to avoid rapid cancellations
!     by newly-arrived streaming WAL entries after reconnection.
     </para>
  
     <para>

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 17 Apr 2014 10:53:34 -0400

> I have developed the attached doc patch to improve the wording on this

Patch applied.

---

From: Marko Tiikkaja <[email-masked]>
Date: Fri, 18 Apr 2014 15:12:37 +0300

> I have developed the attached doc patch to improve the wording on this

I think this is an eloquent phrasing of my understanding of what the 
original text tried to convey.

Regards,
Marko Tiikkaja