RE: xlog loose ends, continued

Поиск
Список
Период
Сортировка
От Mikheev, Vadim
Тема RE: xlog loose ends, continued
Дата
Msg-id 8F4C99C66D04D4118F580090272A7A234D3315@sectorbase1.sectorbase.com
обсуждение исходный текст
Ответ на xlog loose ends, continued  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: xlog loose ends, continued  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> I presume the point of this code was that if we recover and 
> then suffer
> a later crash at a point where we've just written an xlog record that
> exactly fills an xlog page, a subsequent scan of the log 
> might continue
> on from that point and pick up xlog records from the prior (failed)
> system run.  Is there a way to guard against that scenario without
> having to zero out data during recovery?
> 
> One thought that comes to mind is to store StartUpID in XLOG page
> headers, and abort log scanning if we come to a page with StartUpID
> less than what came before.  Is that secure/sufficient?  Is there
> a better way?

This code was from the old days when there was no CRC in log records.
Should we try to read log up to the *physical end* - ie end of last
log file - regardless invalid CRC-s/zero pages with attempt to
re-apply interim valid records? (Or do we already do this?)
This way we'll know where is actual end of log (last valid record)
to begin production from there. (Unfortunately, we'll have to read
empty files pre-created by checkpointer -:().
Anyway I like idea of StartUpID in page headers - this will help
if some log files disappeared. Should we add CRC to page header?
Hm, maybe XLogFileInit should initialize files with StartUpID & CRC
in pages? We would avoid reading empty files.

Vadim


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: xlog checkpoint depends on sync() ... seems unsafe
Следующее
От: Tom Lane
Дата:
Сообщение: Re: xlog loose ends, continued