Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YkVqP-00023t-5a for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Apr 2015 10:55:57 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YkVqO-0008NS-LW for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Apr 2015 10:55:56 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YkVqN-0008NL-7p for pgsql-hackers@postgresql.org; Tue, 21 Apr 2015 10:55:55 +0000 Received: from mail-wg0-x22d.google.com ([2a00:1450:400c:c00::22d]) by makus.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YkVqE-0007Tc-Si for pgsql-hackers@postgresql.org; Tue, 21 Apr 2015 10:55:53 +0000 Received: by wgsk9 with SMTP id k9so208716179wgs.3 for ; Tue, 21 Apr 2015 03:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1tyrhlK13q4dAnvakZ2rNBToq4H8M2ANEkn8TmI0KVk=; b=YOt+PJH9OAqekm6t0bkyNKmaS5supC4gL4OUwbAP2nUyeAm5N1mENe1sYt9esi73ij cpEYKX4WlO9q6zj4uaYkQSTOLcWF8oZYTc4rcPzlx+hKdRmcU68H6Y3IVrK3hapR55PN lVddXxtTpnb/38J6XFuZJRjJ4wgiSlAxLCHvaIgudxv4qOHnkhwWp/Mj+ymRfNZ0ILvU E6s9M3zWL62j21VeXejcAWJh1Pd1WH5yposVOhs8GiW9pXZTXYm5pLR0DkEp4sv6HqH+ QGRAvXoakHu4s4t2I/zolGMhaOYVvSUaxk0w6nngFeiRGnlTstTiQazAw3Qc8tHtWCET 75Iw== X-Received: by 10.180.82.133 with SMTP id i5mr4704730wiy.23.1429613745235; Tue, 21 Apr 2015 03:55:45 -0700 (PDT) Received: from [192.168.1.99] (dsl-hkibrasgw1-58c38f-82.dhcp.inet.fi. [88.195.143.82]) by mx.google.com with ESMTPSA id l10sm2087024wje.15.2015.04.21.03.55.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2015 03:55:44 -0700 (PDT) Message-ID: <55362CAD.2000207@iki.fi> Date: Tue, 21 Apr 2015 13:55:41 +0300 From: Heikki Linnakangas Reply-To: hlinnaka@iki.fi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: Michael Paquier CC: Venkata Balaji N , Andres Freund , Fujii Masao , Borodin Vladimir , PostgreSQL-development Subject: Re: Streaming replication and WAL archive interactions References: <548AF1CB.80702@vmware.com> <689EB259-44C2-4820-B901-4F6B1C55A1E4@simply.name> <549083D6.1000301@vmware.com> <54949108.3030109@vmware.com> <552FA38F.9060005@iki.fi> <5535FE71.1010905@iki.fi> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.4 (--) 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 On 04/21/2015 12:04 PM, Michael Paquier wrote: > On Tue, Apr 21, 2015 at 4:38 PM, Heikki Linnakangas wrote: > >> Note that even though we don't archive the partial last segment on the >> previous timeline, the same WAL is copied to the first segment on the new >> timeline. So the WAL isn't lost. > > But if the failed master has archived those segments safely, we may need > them, no? I am not sure we can ignore a user who would want to do a PITR > with recovery_target_timeline pointing to the one of the failed master. I think it would be acceptable. If you want to maintain an up-to-the-second archive, you can use pg_receivexlog. Mind you, if the standby wasn't promoted, the partial segment would not be present in the archive anyway. And you can copy the WAL segment manually from 0000000200000000000000XX to pg_xlog/0000000100000000000000XX before starting PITR. Another thought is that we could archive the partial file, but with a different name to avoid confusing it with the full segment. For example, we could archive a partial 000000010000000000000012 segment as "000000020000000000000012.00000128.partial", where 00000128 indicates how far that file is valid (this naming is similar to how the backup history files are named). Recovery wouldn't automatically pick up those files, but the DBA could easily copy the partial file into pg_xlog with the full segment's name, if he wants to do PITR to that piece of WAL. >> Are the use cases where you'd want that, rather than the new "shared" >> mode? I wanted to keep the 'on' mode for backwards-compatibility, but if >> that causes more problems, it might be better to just remove it and force >> the admin to choose what kind of a setup he has, with "shared" or "always". > > The 'on' mode is still useful IMO to get a behavior a maximum close to what > previous releases did. But would you ever want the old behaviour, rather than the new shared or always behaviour? - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers