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
