Re: 16-bit page checksums for 9.2

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: 16-bit page checksums for 9.2
Дата
Msg-id 20120206191602.GF19450@momjian.us
обсуждение исходный текст
Ответ на Re: 16-bit page checksums for 9.2  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Mon, Feb 06, 2012 at 12:59:59PM -0500, Bruce Momjian wrote:
> > > I'm also not very comfortable with the idea of having flags on the page
> > > indicating whether it has a checksum or not. It's not hard to imagine a
> > > software of firmware bug or hardware failure that would cause pd_flags field
> > > to be zeroed out altogether. It would be more robust if the expected
> > > bit-pattern was not 0-0, but 1-0 or 0-1, but then you need to deal with that
> > > at upgrade somehow. And it still feels a bit whacky anyway.
> 
> > Good idea. Lets use
> > 
> > 0-0-0 to represent upgraded from previous version, needs a bit set
> > 0-0-1 to represent new version number of page, no checksum
> > 1-1-1 to represent new version number of page, with checksum
> > 
> > So we have 1 bit dedicated to the page version, 2 bits to the checksum indicator
> 
> Interesting point that we would not be guarding against a bit flip from
> 1 to 0 for the checksum bit; I agree using two bits is the way to go.  I
> don't see how upgrade figures into this.
> 
> However, I am unclear how Simon's idea above actually works.  We need
> two bits for redundancy, both 1, to mark a page as having a checksum.  I
> don't think mixing the idea of a new page version and checksum enabled
> really makes sense, especially since we have to plan for future page
> version changes.
> 
> I think we dedicate 2 bits to say we have computed a checksum, and 3
> bits to mark up to 8 possible page versions, so the logic is, in
> pd_flags, we use bits 0x8 and 0x16 to indicate that a checksum is stored
> on the page, and we use 0x32 and later for the page version number.  We
> can assume all the remaining bits are for the page version number until
> we need to define new bits, and we can start storing them at the end
> first, and work forward.  If all the version bits are zero, it means the
> page version number is still stored in pd_pagesize_version.

A simpler solution would be to place two bits for checksum after the
existing page bit usage, and place the page version on the last four
bits of the 16-bit field --- that still leaves us with 7 unused bits.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Report: race conditions in WAL replay routines
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Report: race conditions in WAL replay routines