Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WaUvZ-0005NR-Fx for pgsql-docs@arkaria.postgresql.org; Wed, 16 Apr 2014 18:51:21 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WaUvY-0003DX-Ve for pgsql-docs@arkaria.postgresql.org; Wed, 16 Apr 2014 18:51:21 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WaUvY-0003DR-DS for pgsql-docs@postgresql.org; Wed, 16 Apr 2014 18:51:20 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WaUvV-0001iS-GW for pgsql-docs@postgresql.org; Wed, 16 Apr 2014 18:51:20 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1WaUvT-0000Oz-3L; Wed, 16 Apr 2014 14:51:15 -0400 Date: Wed, 16 Apr 2014 14:51:15 -0400 From: Bruce Momjian To: Fujii Masao Cc: Marko Tiikkaja , pgsql-docs Subject: Re: hot_standby_feedback and max_standby_archive_delay Message-ID: <20140416185115.GI7443@momjian.us> References: <52D86D65.5010000@joh.to> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="k4f25fnPtRuIRUb3" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-docs Precedence: bulk Sender: pgsql-docs-owner@postgresql.org --k4f25fnPtRuIRUb3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Feb 3, 2014 at 01:08:44AM +0900, Fujii Masao wrote: > On Fri, Jan 17, 2014 at 8:38 AM, Marko Tiikkaja 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? I have developed the attached doc patch to improve the wording on this topic. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + --k4f25fnPtRuIRUb3 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="streaming.diff" 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. ! 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. --- 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 ! hot_standby_feedback feedback is not being provided. ! For example, consider increasing 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 ! max_standby_streaming_delay to avoid rapid cancellations ! by newly-arrived streaming WAL entries after reconnection. --k4f25fnPtRuIRUb3 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs --k4f25fnPtRuIRUb3--