Re: Streaming replication and WAL archive interactions
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: hlinnaka <hlinnaka@iki.fi>
Cc: Michael Paquier <michael.paquier@gmail.com>,
Venkata Balaji N <nag1010@gmail.com>,
Andres Freund <andres@anarazel.de>, Fujii Masao <masao.fujii@gmail.com>,
Borodin Vladimir <root@simply.name>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2015-04-21T21:42:28Z
Lists: pgsql-hackers
On Tue, Apr 21, 2015 at 6:55 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > On 04/21/2015 12:04 PM, Michael Paquier wrote: >> On Tue, Apr 21, 2015 at 4:38 PM, Heikki Linnakangas <hlinnaka@iki.fi> >> 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