Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YkfwD-0000E8-FV for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Apr 2015 21:42:37 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YkfwC-0001f1-Q7 for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Apr 2015 21:42:36 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YkfwB-0001et-Cq for pgsql-hackers@postgresql.org; Tue, 21 Apr 2015 21:42:35 +0000 Received: from mail-qc0-x234.google.com ([2607:f8b0:400d:c01::234]) by magus.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Ykfw6-00024H-OJ for pgsql-hackers@postgresql.org; Tue, 21 Apr 2015 21:42:34 +0000 Received: by qcrf4 with SMTP id f4so83329883qcr.0 for ; Tue, 21 Apr 2015 14:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ikts97+pDEano1Q6VjZoHie+RuCPVSF//HcZSHSPUAQ=; b=xK0cMc+njK+nrdWD218/gqvZ6q2co6l8wWwJStKnrrhzwhKG5ccnWUG6W72TwSwwPS 5JvRJt9Lp56XFDkPAqw4PcAmSKLxP2DswLTENKkuN1RXEfSip23kU/yYvByxynpkYkj+ z7/vc9AuWVi88fwANcnPhQgcRqVXLwzRBbO4BlyDWJLGPDmbN1u6+ulB3ZAXS4MyeaB5 U0TXWn2Sdw9dIXHF4kYDPXHySE5LN2zJXh8lcbpfg0CU2cK+EQpunhnBm19Q++PNsUQC FsNvi5x4D83XETbz/Mg/C3nt6o7cDLpu3hX9lHuGTb12d0HsNMOeF45TQG8RHr3rU1/U dcdA== MIME-Version: 1.0 X-Received: by 10.55.31.85 with SMTP id f82mr42420280qkf.6.1429652548274; Tue, 21 Apr 2015 14:42:28 -0700 (PDT) Received: by 10.140.250.139 with HTTP; Tue, 21 Apr 2015 14:42:28 -0700 (PDT) In-Reply-To: <55362CAD.2000207@iki.fi> 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> <55362CAD.2000207@iki.fi> Date: Tue, 21 Apr 2015 17:42:28 -0400 Message-ID: Subject: Re: Streaming replication and WAL archive interactions From: Robert Haas To: hlinnaka Cc: Michael Paquier , Venkata Balaji N , Andres Freund , Fujii Masao , Borodin Vladimir , PostgreSQL-development Content-Type: text/plain; charset=UTF-8 X-Pg-Spam-Score: -2.7 (--) 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 Tue, Apr 21, 2015 at 6:55 AM, Heikki Linnakangas wrote: > 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. So, suppose you A replicating to B (via an archive) replicating to C (via a separate archive); A dies, B is promoted. It sounds to me like today this will work and with your proposed change it will require manual intervention. I don't think that's OK. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers