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 www.2ndQuadrant.com
PostgreSQL Training, Services and Support
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2008-09-29 16:06:43|
|Subject: CTE patch versus UNION type determination rules|
|Previous:||From: Simon Riggs||Date: 2008-09-29 15:32:54|
|Subject: Re: Fatal Errors|
pgsql-patches by date
|Next:||From: Simon Riggs||Date: 2008-09-30 07:01:23|
|Subject: Re: Proposed patch to change TOAST compression strategyfor 8.3.4|
|Previous:||From: Tom Lane||Date: 2008-09-29 15:24:08|
|Subject: Re: [PATCHES] Infrastructure changes for recovery |