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 all light. --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