Date: Mon, 23 Jan 2017 12:23:01 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: julyanto SUTANDANG <julyanto@equnix.co.id>,
	Dinesh Chandra 12108 <Dinesh.Chandra@cyient.com>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Backup taking long time !!!
Message-ID: <20170123172301.GH18360@tamriel.snowman.net>
References: <0fb0c8c3f69340a3a7d70b1c39fa2b2c@cyient.com>
 <CAGu3fER+B6dFk=7F+DEMPPOSerYZs0HZMOfVAkbKs5Gdi-B-mg@mail.gmail.com>
 <CAGu3fERNACLx23C9uARdCb98TJWY_Nd+bMGsBsmo6A8vy01p+A@mail.gmail.com>
 <20170122145740.GE18360@tamriel.snowman.net>
 <CAMkU=1x929ghAR9orvySuxhTGBZmwKABSjy36G=OCBOPsj4_kQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="rKx0vKsfcQ2Qh7ad"
Content-Disposition: inline
In-Reply-To: 
 <CAMkU=1x929ghAR9orvySuxhTGBZmwKABSjy36G=OCBOPsj4_kQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org


--rKx0vKsfcQ2Qh7ad
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Jeff Janes (jeff.janes@gmail.com) wrote:
> On Sun, Jan 22, 2017 at 6:57 AM, Stephen Frost <sfrost@snowman.net> 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.
>=20
> 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.
>=20
> pg_start_backup also forces full_page_writes to be effectively 'on' for t=
he
> 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=3Doff, a=
s it
> ensures that anything in base which got changed mid-copy will be fixed up
> during replay of the WAL.

Agreed.

Thanks!

Stephen

--rKx0vKsfcQ2Qh7ad
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJYhjv1AAoJEO1sijiDR2RVKqsP/0Ie3AHkCp83DZEm6BTr9ayJ
UGmRhxhT23E5cZRGRbSEEMl4/kxW3VtDkguCMtpUCezFfnv4DUTCusFaA0K0t6gZ
+69Kj3f/jiu/CfJ5WtLB0vzx+WYYTD4XQlvALLAJD/ao/hRo7bs74OJy2138QAZz
pCaLFfvHx7uZsrgQ8bR9kX64A/WbGOSwHwO4iB5Q1AO6ToCkMQyFks+vHldmYrGA
+nJyt8xhfnPcfFEsRmrTCCe79baY2wq10MLPPJGtQ3+ISSndVF+YUGNZASObYbrQ
Nca+tL9we18zL7dbeZNJE8Qx+CGGcGB3hHqFgR9jIkN0HtbwjRxMZ/DUG7xF89I6
93qBg3i5a1mjiQQUHsQTfYhg161ueUvcggkLbNMxqiDzlnUvCdMNX4jDYBj0hcqK
d2OBY0Q7/KnFMsYl2V/tZDUxWjeNUgqtZFKC62wLatxX51IOoTauWpRQTBPhqJKZ
1xWLqzErc4C9PmwsxzZtFikwMqAD3n/BrF+mcrT9dcLQbd+EoWZzWg3MJD0ahFzA
fpmyy95JSW8uU7vJnEwBsZ2hDQe44O6jmpVPG3r8CxxfNqmV38AD5QhK+2HeEOEu
Sg+BgdczR1+V+qJiMfaz0PC8Noz/434TV3NF5VaTdQ0LKtA+uH2JNc+kN9IIrEOl
FmBA9VKCplU/qVH3Nq86
=gU9m
-----END PGP SIGNATURE-----

--rKx0vKsfcQ2Qh7ad--