RE: WAL documentation

Поиск
Список
Период
Сортировка
От Mikheev, Vadim
Тема RE: WAL documentation
Дата
Msg-id 8F4C99C66D04D4118F580090272A7A234D32B6@sectorbase1.sectorbase.com
обсуждение исходный текст
Ответ на WAL documentation  ("Oliver Elphick" <olly@lfix.co.uk>)
Ответы Re: WAL documentation  ("Oliver Elphick" <olly@lfix.co.uk>)
Список 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 по дате отправления:

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: Open 7.1 items
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: LEFT JOIN in pg_dumpall is a bug