On Tue, Mar 6, 2012 at 12:50 PM, Bruce Momjian <br...@momjian.us> wrote: > I think the "turning checksums on/off/on/off" is really a killer > problem, and obviously many of the actions needed to make it safe make > the checksum feature itself less useful. > > One crazy idea would be to have a checksum _version_ number somewhere on > the page and in pg_controldata. When you turn on checksums, you > increment that value, and all new checksum pages get that checksum > version; if you turn off checksums, we just don't check them anymore, > but they might get incorrect due to a hint bit write and a crash. When > you turn on checksums again, you increment the checksum version again, > and only check pages having the _new_ checksum version. > > Yes, this does add additional storage requirements for the checksum, but > I don't see another clean option. If you can spare one byte, that gives > you 255 times to turn on checksums; after that, you have to > dump/reload to use the checksum feature.
I don't see what problem that solves. It's just taking the problem we already have and a new failure mode (out of checksum versions) on top of it. If you see a page with checksum version 153 and the current checksum version is 152, then you know that either (a) it is the result of a previous iteration of turning checksums on or (b) the checksum version number got corrupted. This is the exact same problem we have with using a PD_HAS_CHECKSUM bit. If the bit is not set, then you know that either (a) it hasn't been checksummed yet or (b) the bit got corrupted. In either case, a single poorly placed bit-flip gives rise to the exact same confusion. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
