Re: [HACKERS] Checksums by default?

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: [HACKERS] Checksums by default?
Дата
Msg-id 20170124024053.GK18360@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: [HACKERS] Checksums by default?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Checksums by default?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] Checksums by default?  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Jim Nasby <Jim.Nasby@bluetreble.com> writes:
> > On 1/23/17 7:47 PM, Stephen Frost wrote:
> >> It might be interesting to consider checking them in 'clean' pages in
> >> shared_buffers in a background process, as that, presumably, *would*
> >> detect shared buffers corruption.
>
> > Hmm... that would be interesting. Assuming the necessary functions are
> > exposed it presumably wouldn't be difficult to do that in an extension,
> > as a bgworker.
>
> But we don't maintain the checksum of a page while it sits in shared
> buffers.  Trying to do so would break, eg, concurrent hint-bit updates.

Hence why I said 'clean' pages..

Perhaps I'm missing something here, but with checksums enabled, a hint
bit update is going to dirty the page (and we're going to write it into
the WAL and write it out to the heap), no?

We'd have to accept that checking the checksum on a page would require a
read lock on each page as it goes through, I imagine, though we could do
something like check if the page is clean, obtain a read lock, then
check if it's still clean and if so calculate the checksum and then let
the lock go, then at least we're avoiding trying to lock dirty pages.

Thanks!

Stephen

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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: [HACKERS] Checksums by default?
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: [HACKERS] Online enabling of page level checksums