Simon Riggs <[EMAIL PROTECTED]> writes:
> More verbosely (not numbered because they're not a sequence or
> progression)
> - if no recovery.conf is present we do crash recovery to end of logs on
> pg_control timeline (i.e. current)
Check.
> - if recovery.conf is present and we do not specify a target we do
> archive recovery to end of logs on pg_control timeline (i.e. current)
I have done it this way for now, but I'm unconvinced whether this is the
best default --- it might be that we'd be better off making 'latest' be
the default. The point here is that when you restore a tar backup,
'current' is going to become the timeline that was current when the
backup was made, not the one that was current just before you wiped
$PGDATA. I'm not really sure which case is going to be more commonly
wanted.
> - if recovery.conf is present and we specify a target, but no timeline,
> then we do archive recovery on the pg_control timeline only, and assume
> that the target was supposed to be on this, even if we don't find it
Whether you specify a target stopping point does not matter AFAICS. The
timeline selection has to be made before we can even look at the data.
> - if recovery.conf is present and we specify a timeline of literally
> 'latest' (without having to know what that is) - then we search archive
> for the latest history file, then we do archive recovery from the
> pg_control timeline to the latest timeline as specified in the latest
> history file. If we specify a target, then this is searched for on
> whatever timeline we're on as we rollforward.
Check.
> - if recovery.conf is present and we specify a timeline - then we search
> archive for that history file, then we do archive recovery from the
> pg_control timeline to the specified timeline as shown in that history
> file. If we specify a target, then this is searched for on whatever
> timeline we're on as we rollforward.
Check.
>>> I don't like the name target_in_timeline,
>>
>> Agreed, but I don't have a better name offhand for it.
For lack of any better idea, I have swallowed my objections to "target"
and called it "recovery_target_timeline". We can easily rename the
parameter if anyone comes up with something more compelling.
Above behavior is all committed to CVS as of a few minutes ago.
> Another thing I note is that archive_status .ready messages are written
> for all restored xlog files (rather than .done messages).
I think this is gone now. However, we still have the issue of preventing
re-archival of old, incomplete XLOG segments that might be brought back
into pg_xlog/ as a result of restoring a tar backup. I don't have a
better solution to that than the one Bruce and I proposed yesterday
(make the DBA clean out pg_xlog before starting a recovery run).
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
