This commit improves the performance of page-level, or differential
backup, by not having to scan anymore all the pages of a relation file,
something that can be very long on large data sets, but by scanning the
list of blocks changed by WAL records since the last full or differential
backup.
As a restriction and to avoid potential data corruption should hint-bit
updates occur on a page, backups can only be taken from a server that has
wal_log_hints or data checksums enabled.
Base patch by Yury Zhuravlev, heavily modified by me.
--debug and --verbose had actually the same meaning as they were aimed
at giving to the user information regarding how the process is running,
hence both options are merged into --verbose and use elog(LOG) to decide
if a given message should be printed out depending on the verbosity of
the call. This makes a couple of routines more readable as they do not
depend on any boolean checks.
The "_()" have been removed from the code, those are aimed at being used
for translation but having them mandatorily in each log message is just
useless noise. If needed, pgut.c should be updated in consequence to
have a more portable facility.
At the same time this commit takes care of putting into correct shape
some code paths more in-line with PostgreSQL policy. There are surely
more of this kind of ugly stuff but at this stage things are more simple
and more manageable.
Performance of compression is quite questionable on many objects like
that and makes the routines aimed at managing file copy, backup and restore
more complicated than they should be.
This commit results in a largely simplified code in data.c, which will
be helpful when integrating differential backup using WAL file lookup.
This mode is not actually necessary if we consider that the core of
pg_rman is the obtention of differential and full backups, the server
being afterwards in charge to recover necessary WAL segments from the
archive.
Regression tests and documentation are updated in accordance to the
changes.
In order to keep only the core of pg_rman for incremental/differential
backup, this looks necessary and makes the code more simple. Including
server log files in a backup could be subject to discussion as well,
as for example a Postgres base backup does not include them, just
because in this case server instance is not aware of the log files.
Backups could be removed even if generation number was set to infinite
without caring of the day threashold calculated. Backups are removed
if they either satisfy the generation or the day threshold.
This commit simplifies the way backup sizes are saved internally by
reusing the same variable for incremental and full backup, which were
using separated and exclusively used variables, resulted in a couple
of bytes wasted all the time. This was also reflected by a useless
column in the output table of subcommand "show".
Backup from standbys should use a method based on replication protocol
in a way similar to what is done in pg_basebackup, as it cannot use
pg_start/stop_backup. As I am not sure what would be the right approach
by the way, it is better for the time being to block backups taken
from a standby. It does not penalize the functionality though as taking
disk snapshots is not forbidden either, and a user can still recover
from that. This commit removes at the same time some home-made functions
that created custom backup label files, this is not relyable, especially
if Postgres core format for this file changes across versions. Removing
them at least will save from some bugs for sure.
Name file of WAL segment was generated using the API of xlog_internal.h
called XlogFileName, based on XLogSegNo and not XLogRecPtr as the
previous code assumed. This leaded to backup incorrect, actually too
many WAL files in the archive code path because the analysis was based
on a name completely fucked up. This commit fixes at the same time an
issue in search_next_wal where the function could loop for a too long
amount of time, eating much CPU when looking for the next WAL file.
Regression tests are passing cleanly with this patch.
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.
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.
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
