Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VqdKl-0005iv-G3 for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Dec 2013 06:31:47 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VqdKk-0004WY-1x for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Dec 2013 06:31:46 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VqdKi-0004WO-R8 for pgsql-hackers@postgresql.org; Wed, 11 Dec 2013 06:31:45 +0000 Received: from tama50.ecl.ntt.co.jp ([129.60.39.147]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VqdKc-00012N-1q for pgsql-hackers@postgresql.org; Wed, 11 Dec 2013 06:31:40 +0000 Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id rBB6VPDQ006698; Wed, 11 Dec 2013 15:31:25 +0900 Received: from mfs6.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 1F790E0146; Wed, 11 Dec 2013 15:31:25 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 13481E0145; Wed, 11 Dec 2013 15:31:25 +0900 (JST) Received: from [129.60.241.67] ([129.60.241.67]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id rBB6VO9d014371; Wed, 11 Dec 2013 15:31:24 +0900 Message-ID: <52A807F5.4020203@lab.ntt.co.jp> Date: Wed, 11 Dec 2013 15:36:37 +0900 From: KONDO Mitsumasa User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Andres Freund CC: fabriziomello@gmail.com, Robert Haas , Simon Riggs , Pgsql Hackers Subject: Re: Time-Delayed Standbys References: <52A59D10.7020209@lab.ntt.co.jp> <52A5A095.5020002@lab.ntt.co.jp> <20131209112937.GA27840@awork2.anarazel.de> <52A697F3.8030403@lab.ntt.co.jp> <20131210093848.GG27840@awork2.anarazel.de> In-Reply-To: <20131210093848.GG27840@awork2.anarazel.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: No X-Pg-Spam-Score: -2.1 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org (2013/12/10 18:38), Andres Freund wrote: > "master PITR"? What's that? All PITR is based on recovery.conf and thus > not really a "master"? "master PITR" is PITR with "standby_mode = off". It's just recovery from basebackup. They have difference between "master PITR" and "standby" that the former will be independent timelineID, but the latter is same timeline ID taht following the master sever. In the first place, purposes are different. > Why should we prohibit using this feature in PITR? I don't see any > advantage in doing so. If somebody doesn't want the delay, they > shouldn't set it in the configuration file. End of story. Unfortunately, there are a lot of stupid in the world... I think you have these clients, too. > There's not really a that meaningful distinction between PITR and > replication using archive_command. Especially when using > *pause_after. It is meaningless in "master PITR". It will be master which has new timelineID at unexpected timing. > I think this feature will be used in a lot of scenarios in > which PITR is currently used. We have to judge which is better, we get something potential or to protect stupid. And we had better to wait author's comment... Regards, -- Mitsumasa KONDO NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers