Received: from localhost (unknown [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id A99C537BA5A;
	Mon, 29 Sep 2008 12:24:26 -0300 (ADT)
Received: from postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 68873-01; Mon, 29 Sep 2008 12:24:23 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id 9917837BA3A;
	Mon, 29 Sep 2008 12:24:23 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m8TFO83M012424;
	Mon, 29 Sep 2008 11:24:08 -0400 (EDT)
To: Simon Riggs <simon@2ndQuadrant.com>
cc: List pgsql-patches <pgsql-patches@postgresql.org>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PATCHES] Infrastructure changes for recovery 
In-reply-to: <1222700804.4445.1271.camel@ebony.2ndQuadrant> 
References: <1218109459.4549.423.camel@ebony.2ndQuadrant>
	<1220213074.4371.173.camel@ebony.2ndQuadrant>
	<1905.1220895241@sss.pgh.pa.us>
	<1221080797.3913.768.camel@ebony.2ndQuadrant>
	<15776.1221594318@sss.pgh.pa.us>
	<1221725145.3913.2315.camel@ebony.2ndQuadrant>
	<16992.1221743196@sss.pgh.pa.us>
	<1221745847.3913.2408.camel@ebony.2ndQuadrant>
	<18549.1221746983@sss.pgh.pa.us>
	<1222121161.4445.248.camel@ebony.2ndQuadrant>
	<1222184541.4445.400.camel@ebony.2ndQuadrant>
	<28973.1222381719@sss.pgh.pa.us>
	<1222424415.4445.917.camel@ebony.2ndQuadrant>
	<9794.1222624945@sss.pgh.pa.us>
	<1222649659.4445.1061.camel@ebony.2ndQuadrant>
	<22856.1222650961@sss.pgh.pa.us>
	<1222691596.4445.1188.camel@ebony.2ndQuadrant>
	<10307.1222692406@sss.pgh.pa.us>
	<1222696408.4445.1229.camel@ebony.2ndQuadrant>
	<11540.1222697639@sss.pgh.pa.us>
	<1222700804.4445.1271.camel@ebony.2ndQuadrant>
Comments: In-reply-to Simon Riggs <simon@2ndQuadrant.com>
	message dated "Mon, 29 Sep 2008 16:06:44 +0100"
Date: Mon, 29 Sep 2008 11:24:08 -0400
Message-ID: <12423.1222701848@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none
X-Spam-Level: 
X-Archive-Number: 200809/1811
X-Sequence-Number: 124940

Simon Riggs <simon@2ndQuadrant.com> writes:
> On Mon, 2008-09-29 at 10:13 -0400, Tom Lane wrote:
>> ... If we crash and restart, we'll have to get to the end
>> of this file before we start letting backends in; which might be further
>> than we actually got before the crash, but not too much further because
>> we already know the whole WAL file is available.

> Don't want to make it per file though. Big systems can whizz through WAL
> files very quickly, so we either make it a big number e.g. 255 files per
> xlogid, or we make it settable (and recorded in pg_control).

I think you are missing the point I made above.  If you set the
okay-to-resume point N files ahead, and then the master stops generating
files so quickly, you've got a problem --- it might be a long time until
the slave starts letting backends in after a crash/restart.

Fetching a new WAL segment from the archive is expensive enough that an
additional write/fsync per cycle doesn't seem that big a problem to me.
There's almost certainly a few fsync-equivalents going on in the
filesystem to create and delete the retrieved segment files.

			regards, tom lane