On Sat, Sep 14, 2019 at 12:20 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Fri, Sep 13, 2019 at 01:47:03PM -0400, James Coleman wrote:
> > So I've attached a patch to summarize more correctly as well as
> > document clearly the state of the cluster after the operation and also
> > the operation sequencing dangers caused by copying configuration
> > files from the source.
>
> + After a successful rewind, the target data directory is equivalent
> to the
> + to the state of the data directory at the point at which the
> source and
> + target diverged plus the current state on the source of any blocks
> changed
> + on the target after that divergence. While only changed blocks
> from relation
> + files are copied; all other files are copied in full, including
> configuration
> + files and WAL segments. The advantage of
> <application>pg_rewind</application>
> + over taking a new base backup, or tools like
> <application>rsync</application>,
> + is that <application>pg_rewind</application> does not require
> comparing or
> + copying unchanged relation blocks in the cluster. As such the
> rewind operation
> + is significantly faster than other approaches when the database is
> large and
> + only a small fraction of blocks differ between the clusters.
>
> The point of divergence could be defined as the LSN position where WAL
> has forked on the new timeline, but the block diffs are copied from
> actually the last checkpoint just before WAL has forked. So this new
> paragraph brings confusion about the actual divergence point.
>
> Regarding the relation files, if the file does not exist on the target
> but does exist on the source, it is also copied fully, so the second
> sentence is wrong here to mention as relation files could also be
> copied fully.
Updated (plus some additional wordsmithing).
James Coleman