Version 2.0.17

    - Fix: correct handling for tablespaces located in PGDATA
    - Fix: avoid deadlock in log file opening
    - Fix: check PQresultStatus for pg_stop_backup()
    - Fix: null-sized files were not copied to backup
    - Impromevent: correct thread exit
    - Impromevent: correct message about start/stop WAL streaming
    - Impromevent: revalidation of CORRUPT and ORPHAN backups is now possible via 'validate' command
    - New backup options:
       '-b DELTA' - new incremental backup mode;
    - New restore options:
       '--immediate' - end recovery as soon as a consistent state is reached;
       '--recovery-target-name=pause|promote|shutdown' - an action the PostgreSQL should take at the end of the recovery, default is 'pause';
       '--recovery-target-name=target-name' - the named restore point to which recovery will proceed;
       '-R (--write-recovery-conf)' - write a minimal recovery.conf in the output directory, to ease setting up a standby server;
    - Adjust README

Author: gsmolk

README.md

@@ -27,7 +27,7 @@ Using `pg_probackup`, you can take full or incremental backups:
 * `Full` backups contain all the data files required to restore the database cluster from scratch.
 * `Incremental` backups only store the data that has changed since the previous backup. It allows to decrease the backup size and speed up backup operations. `pg_probackup` supports the following modes of incremental backups:
   * `PAGE` backup. In this mode, `pg_probackup` scans all WAL files in the archive from the moment the previous full or incremental backup was taken. Newly created backups contain only the pages that were mentioned in WAL records. This requires all the WAL files since the previous backup to be present in the WAL archive. If the size of these files is comparable to the total size of the database cluster files, speedup is smaller, but the backup still takes less space.
-  * `DELTA` backup. In this mode, `pg_probackup` read all data files in PGDATA directory and only those pages, that where changed since previous backup, are copied. Continuous archiving is not necessary for it to operate. Also this mode impose I/O stress equal to `Full` backup and takes the same amount of time.
+  * `DELTA` backup. In this mode, `pg_probackup` read all data files in PGDATA directory and only those pages, that where changed since previous backup, are copied. Continuous archiving is not necessary for it to operate. Also this mode could impose read-only I/O pressure equal to `Full` backup.
   * `PTRACK` backup. In this mode, PostgreSQL tracks page changes on the fly. Continuous archiving is not necessary for it to operate. Each time a relation page is updated, this page is marked in a special `PTRACK` bitmap for this relation. As one page requires just one bit in the `PTRACK` fork, such bitmaps are quite small. Tracking implies some minor overhead on the database server operation, but speeds up incremental backups significantly.
 
 Regardless of the chosen backup type, all backups taken with `pg_probackup` support the following archiving strategies:
@@ -67,7 +67,7 @@ yum install pg_probackup-{10,9.6,9.5}
 rpm -ivh http://repo.postgrespro.ru/pg_probackup/keys/pg_probackup-repo-oraclelinux.noarch.rpm
 yum install pg_probackup-{10,9.6,9.5}
 
-#SRPM Oracle Linux Packages
+#SRPM Packages
 yumdownloader --source pg_probackup-{10,9.6,9.5}
 ```