database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-16 06:01:02 +03:00
Code Activity

Make archive recovery always start a new timeline, rather than only when a

Browse Source 
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.
This commit is contained in:
Tom Lane
2007-09-29 01:36:10 +00:00
parent b37e1770c5
commit b46bd55a6c
2 changed files with 22 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
doc/src/sgml/backup.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.102 2007/09/26 22:36:30 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.103 2007/09/29 01:36:10 tgl Exp $ -->
<chapter id="backup">
<title>Backup and Restore</title>
@ -1174,11 +1174,9 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
<para>
To deal with these problems, <productname>PostgreSQL</> has a notion
of <firstterm>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 <firstterm>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