This commit makes mandatory the presence of a full backup when doing
an incremental or archive backup on an existing timeline. In this case
the process will now simply error out and not take any backup. It looks
safer to use that as a default by the way, so as user will be forced
to take a full backup once a recovery has been done.
Database backup also contained the following condition when doing an
incremental backup:
prev_backup->tli != current.tli
This means that an incremental backup cannot be taken if there is not
already a full backup present in the same timeline. The same condition
should also be used for archive backup but it didn't seem to be the
case...
This bug has been introduced by some older code, it looks that it will be
necessary to re-create a battery of regression tests to test all those
things automtically, as former tests contain nothing to test archive
mode directly.
Those macros were mainly used in code paths where they didn't make that
much sense, complicating heavily the code. Correct at the same time some
code comments.
It was unclear what was being errored out at the beginning of the
process. But it happens that it is just necessary to check if the
backup running is only an archive or not, then return a NULL file
list before continuing process. This should be part of some safety
checks though.
The documentation found on internet is rather unclear about the role
and the goal of this feature, which looks more like a kludge to cover
the fact that most of the system XLOG functions do not work on standby
nodes. Now that this restriction has been removed by using the control
file to look for the current timestamp, this feature is not needed.
The system function used up to now was pg_xlogfile_name_offset, which
cannot be used on a node in recovery, and it was the only way present
to fetch the timeline ID of a backup, either incremental or full. So
instead scan the control file of server and fetch the timeline from
that. This also removes the restriction on which a backup could not
be taken on a standby node. The next step being to have the possibility
to take backups from streams.
It is just troublesome to have to type a subcommands for something that
could be merged into a single table. The output could be made in a
smarter way though...
Due to changes in XlogRecPtr in 9.3, older version of pg_rman are
already incompatible either way, and it is a pain to maintain code
duplicated from past versions of Postgres, so rely a maximum on the
core structures.
History file format has changed from 9.2 to 9.3 to indicate the WAL record
when timeline branched off. In 9.2, the complete WAL file name was used
while in 9.3 the WAL record is used (like 1/4000090). pg_rman contains a
copy of a function of postgres core code to parse the history file that
was not anymore compatible, leading to errors related to timelines.
In Postgres 9.3, XLogRecPtr has been changed to a unique uint64, making
the old structure based on two uint32 obsolete. Note that this makes
pg_rman incompatible with PG <= 9.2.
Use --standby-host and --standby-port, if backup is getting from standby.
- Add --hard-copy restore option.
The option can be used to copy archive WAL to archive directory instead of symlink.
git-svn-id: http://pg-rman.googlecode.com/svn/trunk@77 182aca00-e38e-11de-a668-6fd11605f5ce
Fix a bug about --recovery-target-time.
Fix SPEC files for using normal user. (Reported by Nagayasu-san)
Fix a compiling bug on no LZLib environment.
Add restriction about Incremental backup.
git-svn-id: http://pg-rman.googlecode.com/svn/trunk@71 182aca00-e38e-11de-a668-6fd11605f5ce
