Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1aEInl-0007Pw-4V for pgsql-bugs@arkaria.postgresql.org; Wed, 30 Dec 2015 15:36:37 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aEInk-0005wc-M0 for pgsql-bugs@arkaria.postgresql.org; Wed, 30 Dec 2015 15:36:36 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aEIn8-0005Ff-HT for pgsql-bugs@postgresql.org; Wed, 30 Dec 2015 15:35:58 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aEIn5-0006lK-Jc for pgsql-bugs@postgresql.org; Wed, 30 Dec 2015 15:35:58 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id tBUFZm7f011508; Wed, 30 Dec 2015 10:35:48 -0500 From: Tom Lane To: Andres Freund cc: Michael Paquier , Greg Clough , PostgreSQL mailing lists , Simon Riggs Subject: Re: BUG #13770: Extending recovery_min_apply_delay on Standby causes it to be unavailable for a while In-reply-to: <20151230140218.5jqkq3rjoejlrgq7@alap3.anarazel.de> References: <20151111155006.2644.84564@wrigleys.postgresql.org> <20151230140218.5jqkq3rjoejlrgq7@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Wed, 30 Dec 2015 15:02:18 +0100" Date: Wed, 30 Dec 2015 10:35:48 -0500 Message-ID: <11507.1451489748@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-bugs Precedence: bulk Sender: pgsql-bugs-owner@postgresql.org Andres Freund writes: > On 2015-12-26 22:45:57 +0900, Michael Paquier wrote: >> Depending on the use cases, it may be interesting to have a switch >> allowing to not apply the delay should a consistent point not be >> reached though... > Is there actually any case where it's interesting to delay in that > scenario? I mean that really can only happen if you changed the > configuration to a different delay, or your clock offset > changed. Otherwise we should always reach the consistent point before > the delay plays a role. I'm tempted to simply only check for delay when > consistent. The argument for having a delay at all is to allow backing up to some earlier point in the master's history; but a slave that is not yet consistent cannot provide any rollback/recovery option. The slave is completely useless for any purpose until it reaches consistency, so it might as well do that as fast as possible, and then sit on the next WAL record until the delay is met. +1 for no delay at all when not consistent. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs