Re: Proposal: Integrity check

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas ADI SD
Тема Re: Proposal: Integrity check
Дата
Msg-id E1539E0ED7043848906A8FF995BDA57902B63125@m0143.s-mxs.net
обсуждение исходный текст
Ответ на Re: Proposal: Integrity check  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Proposal: Integrity check  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> >> This seems like a pretty horrid idea.  Bad pages shouldn't be
allowed to
> >> get into shared buffers in the first place.  Why not have the
checking
> >> logic operate outside shared buffers?
>
> > It currently works outside the shared buffers, but I afraid about
> > collision due to parallel read and write access on one block. I'm
not
> > sure if parallel write(8k) and read(8k) is synchronized by kernel/fs
or
> > not. If not it should generates false positive results. If yes than
I'm
> > happy :-) with outside processing.
>
> We're already assuming that; otherwise base backups for PITR
> don't work.

I think we could, but iirc we did not. We do not need that assumption if
you don't
turn off fullpage writes. All pages that could potentially be changed
during the
backup exist in the WAL fullpages that have to be replayed.
Don't we even now allways write fullpages to WAL during backup exactly
because we
did not confirm that assumption ?

I think I recall times when some OS had trouble with this when you mixed
O_DIRECT (or was it also O_DATASYNC) and normal IO.

Andreas



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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Truncate Triggers
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Proposal: Integrity check