On Mon, 2008-09-29 at 08:46 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
