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 14:53:28 +0100
Message-ID: <1222696408.4445.1229.camel@ebony.2ndQuadrant> (raw)
In-Reply-To: <10307.1222692406@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>


On Mon, 2008-09-29 at 08:46 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > ... That kinda works, but the problem is that restartpoints are time based,
> > not log based. We need them to be deterministic for us to rely upon them
> > in the above way.
> 
> Right, but the performance disadvantages of making them strictly
> log-distance-based are pretty daunting.  We don't really want slaves
> doing that while they're in catchup mode.

I don't think we need to perform restartpoints actually, now I think
about it. It's only the LSN that is important. 

I think we can get away with writing the LSN value to disk, as you
suggested, but only every so often. No need to do it after every WAL
record, just consistently every so often, so it gives us a point at
which we know we are safe. We will need to have Startup process block
momentarily while the value is written.

Propose Startup process writes/flushes LSN to pg_control every time we
change xlogid. That's independent of WAL file size and fairly clear. 

When we reach that LSN + 1 we will know that no LSNs higher than that
value can have reached disk.

OK?

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




view thread (52+ messages)  latest in thread

Message-ID: <1222696408.4445.1229.camel@ebony.2ndQuadrant>
Permalink:  ../1222696408.4445.1229.camel@ebony.2ndQuadrant/
Also on:    postgresql.org/message-id/1222696408.4445.1229.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: <1222696408.4445.1229.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