Re: [HACKERS] Checksums by default? - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [HACKERS] Checksums by default?
Date
Msg-id 20170124024053.GK18360@tamriel.snowman.net
Whole thread Raw
In response to Re: [HACKERS] Checksums by default?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Checksums by default?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] Checksums by default?  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Jim Nasby
Date:
Subject: Re: [HACKERS] Checksums by default?
Next
From: Jim Nasby
Date:
Subject: Re: [HACKERS] Online enabling of page level checksums