Date: Thu, 11 Feb 2010 12:31:54 -0500
From: Aidan Van Dyk <aidan@highrise.ca>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Simon Riggs <simon@2ndQuadrant.com>, Fujii Masao <masao.fujii@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server
	continuously retry  restoring the next WAL
Message-ID: <20100211173154.GD14128@oak.highrise.ca>
References: <1265884657.7341.1192.camel@ebony>
	<4B73F678.8070109@enterprisedb.com>
	<1265891248.7341.1346.camel@ebony>
	<4B73FB99.4080403@enterprisedb.com>
	<1265893599.7341.1454.camel@ebony>
	<4B740613.5090004@enterprisedb.com>
	<20100211140118.GB14128@oak.highrise.ca>
	<4B74118C.30704@enterprisedb.com>
	<20100211144204.GC14128@oak.highrise.ca>
	<4B7438A9.8090902@enterprisedb.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="DO5DiztRLs659m5i"
Content-Disposition: inline
In-Reply-To: <4B7438A9.8090902@enterprisedb.com>
User-Agent: Mutt/1.5.18 (2008-05-17)


--DO5DiztRLs659m5i
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

* Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> [100211 12:04]:

> > But it can be a problem - without the last WAL (or at least enough of
> > it) the master switched and archived, you have no guarantee of having
> > being consistent again (I'm thinking specifically of recovering from a
> > fresh backup)
> 
> You have to wait for the last WAL file required by the backup to be
> archived before starting recovery. Otherwise there's no guarantee anyway.

Right, but now define "wait for".  If you pull only "half" the last WAL
(because you've accepted that you *can* have short WAL files in the
archive), you have the problem with PITR.

Is it "wait for it to be in the archive", or "wait for it to be in the
archive, and be sure that the contents satisfy some criteria".

I've always made my PITR such that "in the archive" (i.e. the first
moment a recovery can see it) implies that it's bit-for-bit identical to
the original (or at least as bit-for-bit I can assume by checking
various hashes I can afford to).  I just assumed that was kind of common
practice.

I'm amazed that "partial WAL" files are every available in anyones
archive, for anyone's  restore command to actually pull.  I find that
scarry, and sure, probably won't regularly be noticed... But man, I'ld
hate the time I need that emergency PITR restore to be the one time when
it needs that WAL, pulls it slightly before the copy has finished (i.e.
the master is pushing the WAL over a WAN to a 2nd site), and have my
restore complete consistently...

a.


-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFLdD8KuVxNPsxNPScRAic6AKCw/xvZeNE4iENfWrjFJAm790ehbwCgsLNa
4xyeDyxyUHkjxRVbuKNvGT0=
=FEa9
-----END PGP SIGNATURE-----

--DO5DiztRLs659m5i--