RE: WAL documentation - Mailing list pgsql-hackers

From Mikheev, Vadim
Subject RE: WAL documentation
Date
Msg-id 8F4C99C66D04D4118F580090272A7A234D32B6@sectorbase1.sectorbase.com
Whole thread Raw
In response to WAL documentation  ("Oliver Elphick" <olly@lfix.co.uk>)
Responses Re: WAL documentation
List pgsql-hackers
> 1) In the 'WAL Parameters' section, paragraph 3 there is the following
> sentence: "After a checkpoint has been made, any log segments written
> before the redo record may be removed/archived..."  What does the 'may'
> refer mean? Does the database administrator need to go into the 
> directory and remove the no longer necessary log files?  What does
> archiving have to do with this? If I archived all log files, could
> I roll forward a backup made previously? That is the only reason I can
> think of that you would archive log files (at least that is why you
> archive log files in Oracle).

Offline log segments are removed automatically at checkpoint time.
WAL based BAR is not implemented yet, so no archiving is made
currently.

> 2) The doc doesn't seem to explain how on database recovery 
> the database knows which log file to start with. I think walking
> through an example of how after a database crash, the log file is
> used for recovery, would be useful. At least it would make me as
> a user of postgres feel better if I understood how crashes are
> recovered from.

After checkpoint is made (log flushed) its position is saved in
pg_control file. So, on recovery backend first read pg_control,
than checkpoint record, than redo record (its position is saved
in checkpoint) and begins REDO op. Because of entire content of
pages is saved in log on first-after-checkpoint page modification
pages will be first restored to consistent stage.

Using pg_control to get checkpoint position speed up things but
to handle possible pg_control corruption we obviously should
implement reading existent log segments (from the last one -
newest - to oldest) to get last checkpoint.

Vadim


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Open 7.1 items
Next
From: Peter Eisentraut
Date:
Subject: Re: LEFT JOIN in pg_dumpall is a bug