On Sat, Sep 14, 2019 at 12:20 AM Michael Paquier <mich...@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
001_pg_rewind_explanation_doc_fixes_v2.patch
Description: Binary data
