index 91da3c26ba03ed67362098c852d91ffdc42c87a0..e4e4c56cf14032131d64014538c571482cee8576 100644 (file)
@@ -925,6 +925,17 @@ test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_wal/0
to manage. For a large database all of which is heavily modified,
incremental backups won't be much smaller than full backups.
</para>
+
+ <para>
+ An incremental backup is only possible if replay would begin from a later
+ checkpoint than for the previous backup upon which it depends. If you
+ take the incremental backup on the primary, this condition is always
+ satisfied, because each backup triggers a new checkpoint. On a standby,
+ replay begins from the most recent restartpoint. Therefore, an
+ incremental backup of a standby server can fail if there has been very
+ little activity since the previous backup, since no new restartpoint might
+ have been created.
+ </para>
</sect2>
<sect2 id="backup-lowlevel-base-backup">
index 21087023973e4d162354fb64ad689a21b64a46b3..a023e6244035bfc676944d5e1f0b36525c7f6eef 100644 (file)
@@ -441,7 +441,8 @@ PrepareForIncrementalBackup(IncrementalBackupInfo *ib,
errmsg("manifest requires WAL from final timeline %u ending at %X/%X, but this backup starts at %X/%X",
range->tli,
LSN_FORMAT_ARGS(range->end_lsn),
- LSN_FORMAT_ARGS(backup_state->startpoint))));
+ LSN_FORMAT_ARGS(backup_state->startpoint)),
+ errhint("This can happen for incremental backups on a standby if there was little activity since the previous backup.")));
}
else
{