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.
--
Michael