From 4ef631fe2c1185c85fabdaa495e0562bd0d41741 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sat, 29 Sep 2007 01:36:19 +0000 Subject: Make archive recovery always start a new timeline, rather than only when a recovery stop time was used. This avoids a corner-case risk of trying to overwrite an existing archived copy of the last WAL segment, and seems simpler and cleaner all around than the original definition. Per example from Jon Colverson and subsequent analysis by Simon. --- doc/src/sgml/backup.sgml | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml index 36856b692df..1640c67fd67 100644 --- a/doc/src/sgml/backup.sgml +++ b/doc/src/sgml/backup.sgml @@ -1,4 +1,4 @@ - + Backup and Restore @@ -1134,11 +1134,9 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows To deal with these problems, PostgreSQL has a notion - of timelines. Each time you recover to a point-in-time - earlier than the end of the WAL sequence, a new timeline is created - to identify the series of WAL records generated after that recovery. - (If recovery proceeds all the way to the end of WAL, however, we do not - start a new timeline: we just extend the existing one.) The timeline + of timelines. Whenever an archive recovery is completed, + a new timeline is created to identify the series of WAL records + generated after that recovery. The timeline ID number is part of WAL segment file names, and so a new timeline does not overwrite the WAL data generated by previous timelines. It is in fact possible to archive many different timelines. While that might -- cgit v1.2.3