pg.ddx.io  pgsql-patches@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Simon Riggs <simon@2ndQuadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: List pgsql-patches <pgsql-patches@postgresql.org>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PATCHES] Infrastructure changes for recovery
Date: Mon, 29 Sep 2008 16:54:55 +0100
Message-ID: <1222703695.4445.1283.camel@ebony.2ndQuadrant> (raw)
In-Reply-To: <12423.1222701848@sss.pgh.pa.us>
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>
	<12423.1222701848@sss.pgh.pa.us>


On Mon, 2008-09-29 at 11:24 -0400, Tom Lane wrote:
> 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.

Didn't miss yer point, just didn't agree. :-)

I'll put it at one (1) and then wait for any negative perf reports. No
need to worry about things like that until later.

-- 
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support




view thread (52+ messages)  latest in thread

Message-ID: <1222703695.4445.1283.camel@ebony.2ndQuadrant>
Permalink:  ../1222703695.4445.1283.camel@ebony.2ndQuadrant/
Also on:    postgresql.org/message-id/1222703695.4445.1283.camel@ebony.2ndQuadrant

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-patches@postgresql.org
  Cc: simon@2ndQuadrant.com, tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org
  Subject: Re: [PATCHES] Infrastructure changes for recovery
  In-Reply-To: <1222703695.4445.1283.camel@ebony.2ndQuadrant>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox