Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] Infrastructure changes for recovery

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: List pgsql-patches <pgsql-patches(at)postgresql(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] Infrastructure changes for recovery
Date: 2008-09-29 15:54:55
Message-ID: 1222703695.4445.1283.camel@ebony.2ndQuadrant (view raw or whole thread)
Lists: pgsql-hackerspgsql-patches
On Mon, 2008-09-29 at 11:24 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)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 
 PostgreSQL Training, Services and Support

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2008-09-29 16:06:43
Subject: CTE patch versus UNION type determination rules
Previous:From: Simon RiggsDate: 2008-09-29 15:32:54
Subject: Re: Fatal Errors

pgsql-patches by date

Next:From: Simon RiggsDate: 2008-09-30 07:01:23
Subject: Re: Proposed patch to change TOAST compression strategyfor 8.3.4
Previous:From: Tom LaneDate: 2008-09-29 15:24:08
Subject: Re: [PATCHES] Infrastructure changes for recovery

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group