On 04/21/2015 12:04 PM, Michael Paquier wrote:
On Tue, Apr 21, 2015 at 4:38 PM, Heikki Linnakangas <hlinn...@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.
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
