Обсуждение: Re: WAL replay logic (was Re: [PERFORM] Mount options f
> > > Added to TODO: > > > > > > * Allow WAL information to recover corrupted pg_controldata > > >... > > > > Using pg_control to get the checkpoint position > speeds up the > > > > recovery process, but to handle possible > corruption of pg_control, > > > > we should actually implement the reading of > existing log segments > > > > in reverse order -- newest to oldest -- in order > to find the last > > > > checkpoint. This has not been implemented, yet. > > > > So if you do this, do you still need to store that information in > > pg_control at all? Yes: to "speeds up the recovery process". Vadim _____________________________________________________ Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC
On Tue, 18 Feb 2003, Mikheev, Vadim wrote: > > > So if you do this, do you still need to store that information in > > > pg_control at all? > > Yes: to "speeds up the recovery process". If it's going to slow down the performance of my database when not doing recovery (because I have to write two files for every transaction, rather than one), I couldn't care less about speeding up the recovery process. As far as Bruce's question goes, what kind of corruption can happen to the log files? We write a full block at a time, I guess, so it might make sense to checksum it to verify that the block was not partially written. cjs -- Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're alllight. --XTC
> > > > So if you do this, do you still need to store that information in > > > > pg_control at all? > > > > Yes: to "speeds up the recovery process". > > If it's going to slow down the performance of my database when not doing > recovery (because I have to write two files for every transaction, > rather than one) Control file is not updated "for every transaction", only on a few special events like checkpoint. Vadim