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
signature.asc
Description: PGP signature