Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eMPJZ-0005IY-1y for pgsql-docs@arkaria.postgresql.org; Wed, 06 Dec 2017 02:20:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eMPJY-0000FK-Lx for pgsql-docs@arkaria.postgresql.org; Wed, 06 Dec 2017 02:20:00 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eMPJY-0000FA-Db for pgsql-docs@lists.postgresql.org; Wed, 06 Dec 2017 02:20:00 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eMPJV-00012i-TL for pgsql-docs@postgresql.org; Wed, 06 Dec 2017 02:19:59 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B320420B96; Tue, 5 Dec 2017 21:19:56 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Tue, 05 Dec 2017 21:19:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=3lflic gh5xCOKMHajkOoqY/8gBf1H15YsAwvM82gs08=; b=kcMd2yOL3INNVc6acl8Hlv pHrHBA+WUPW5n2OBk0/WthNPI8c9c3jzDzmRmp9EqAtzzikYcRAKB3b8dO9lImrJ rQnV4ZMKltD2wa3DbpNZc7VA213t8qiGvrEgF23fM66iycriDSV/QxuZ4uJxytAW 0UkTEt7pUb76+zrZWyK4rGNN006sigif6r+i2nI4SGh4pVH8PMfVkOklVJtIV3IH V+aMvRnDknd82FjGUeoQN3MrspAqoLnt47FTjldJDkvc/yPYtdDEVTw3lTHzRw+d iK7kRveQY8BP1U/6FctMuS/gZgQRBF8lbR1t9Va8vf8Ue1FOXIIqLL1hiFR1B4rQ == X-ME-Sender: Received: from april.local (c-73-13-66-39.hsd1.pa.comcast.net [73.13.66.39]) by mail.messagingengine.com (Postfix) with ESMTPA id 6293E24786; Tue, 5 Dec 2017 21:19:56 -0500 (EST) Subject: Re: Replication parameters in recovery.conf To: Aleksandr Parfenov , pgsql-docs@postgresql.org References: <20171201141236.35f6a90d@asp437-24-g082ur> From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: Date: Tue, 5 Dec 2017 21:19:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171201141236.35f6a90d@asp437-24-g082ur> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 12/1/17 06:12, Aleksandr Parfenov wrote: > Reading a documentation regarding recovery.conf file I found that the > reason to store 'stand-by mode' configuration inside that file is not > clear. > > IMHO, a little note in description of recovery.conf will clearify > the situation. Something like "a stand-by is submode of recover mode" > and that the file used during replication will help. Same as in > recovery.conf.sample file will be fine too. > > What the community thinks about it? The reasons for this are basically all historical and we are trying to get rid of it (by moving these settings to postgresql.conf, mostly). So I don't think we need to spend a lot of time rationalizing this at this point. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services