Date: Thu, 11 Feb 2010 09:42:04 -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: <20100211144204.GC14128@oak.highrise.ca>
References: <3f0b79eb1002092105r21e009d3v468496058ba04392@mail.gmail.com>
	<4B726120.80007@enterprisedb.com>
	<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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="fWddYNRDgTk9wQGZ"
Content-Disposition: inline
In-Reply-To: <4B74118C.30704@enterprisedb.com>
User-Agent: Mutt/1.5.18 (2008-05-17)


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

* Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> [100211 09:17]:

> If the file is just being copied to the archive when restore_command
> ('cp', say) is launched, it will copy a half file. That's not a problem
> for PITR, because PITR will end at the end of valid WAL anyway, but
> returning a half WAL file in standby mode is a problem.

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)

> Yeah, if you're careful about that, then this change isn't required. But
> pg_standby protects against that, so I think it'd be reasonable to have
> the same level of protection built-in. It's not a lot of code.

This 1 check isn't, but what about the rest of the things pg_standby
does.  How much functionality should we bring it?  Ideally, "all" of it.

> We could well just document that you should do that, ie. make sure the
> file appears in the archive atomically with the right size.

I have to admit, today was the first time I went and re-read the PITR
docs, and no, the docs don't seem to talk about that... Maybe it was
just plain obvious to me because it (the atomic apperance) is something
unix devloppers have always had to deal with, so it's ingrained in me.
But I'm *sure* that I've seen that bandied around as common knowledge on
the lists, and one of the reasons we alway see warnings about using
rsync instead of plain SCP, etc.

So ya, we should probably mention that somewhere in the docs.  Section
24.3.6. Caveats?

a.

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

--fWddYNRDgTk9wQGZ
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)

iD8DBQFLdBc8uVxNPsxNPScRAjcxAKCvGRT2cl+zYNpnjgfHRW8sFibP0gCfZZf2
cSZZiGjSnoC+EIPhjvzC4sY=
=ExJZ
-----END PGP SIGNATURE-----

--fWddYNRDgTk9wQGZ--