Re: using pg_basebackup for point in time recovery

On Thu, Jun 21, 2018 at 4:26 PM, Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>
wrote:

> On 21/06/18 07:27, Michael Paquier wrote:
> > Attached is a patch which includes your suggestion. What do you think?
> > As that's an improvement, only HEAD would get that clarification.
>
> Say what? If the clarification applies to previous versions, as it
> does, it should be backpatched. This isn't a change in behavior, it's a
> change in the description of existing behavior.
>

Generally only actual bug fixes get back-patched; but I'd have to say this
looks like it could easily be classified as one.

Before: These are backups that cannot be used for PITR
After: These are backups that could be used for PITR if ...

Changing a cannot to a can seems like we are fixing a bug in the
documentation.

Some comments on the patch itself:

"recover up to the wanted recovery point." - "desired recovery point" reads
better to me

====
"These backups are typically much faster to backup and restore" - "These
backups are typically much faster to create and restore"; avoid repeated
use of the word backup

"but can result as well in larger backup sizes" - "but can result in larger
backup sizes", drop the unnecessary 'as well'

"sizes, so the speed of one method or the other is to evaluate carefully
first" - that is just wrong as-is; suggest just removing it.
====

To cover the last three items as a whole I'd suggest:

"These backups are typically much faster to create and restore, but
generate larger file sizes, compared to pg_dump."

For the last sentence I'd suggest:

"Note that because WAL cannot be applied on top of a restored pg_dump
backup it is considered a cold backup and cannot be used for
point-in-time-recovery."

I like adding "cold backup" here to help contrast and explain why a base
backup is considered a "hot backup". The rest is style to make that flow
better.

David J.