* Jeff Janes (jeff.janes@xxxxxxxxx) wrote: > On Sun, Jan 22, 2017 at 6:57 AM, Stephen Frost <sfrost@xxxxxxxxxxx> wrote: > > Just to make sure anyone reading the mailing list archives isn't > > confused, running pg_start_backup does *not* make PG stop writing to > > BASEDIR (or DATADIR, or anything, really). PG *will* continue to write > > data into BASEDIR after pg_start_backup has been called. > > Correct. Unfortunately it is a very common myth that it does cause > PostgreSQL to stop writing to the base dir. I would love a way to dispel that myth. :/ If you have any suggestions of how we could improve the docs, I'd certainly be happy to take a look and try to help. > > The only thing that pg_start_backup does is identify an entry in the WAL > > stream, from which point all WAL must be replayed when restoring the > > backup. All WAL generated from that point (pg_start_backup point) until > > the pg_stop_backup point *must* be replayed when restoring the backup or > > the database will not be consistent. > > pg_start_backup also forces full_page_writes to be effectively 'on' for the > duration of the backup, if it is not already explicitly on (which it > usually will already be). This affects pg_xlog, of course, not base. But > it is an essential step for people who run with full_page_writes=off, as it > ensures that anything in base which got changed mid-copy will be fixed up > during replay of the WAL. Agreed. Thanks! Stephen
Attachment:
signature.asc
Description: Digital signature
