Re: 16-bit page checksums for 9.2

On Mon, Feb 20, 2012 at 11:23:42PM +0000, Simon Riggs wrote:
> > If you use pg_upgrade, and enable the checksum GUC, your database will
> > become progressively checksummed, and as Simon pointed out, the only
> > clean way is VACUUM FULL.  It is quite hard to estimate the checksum
> > coverage of a database with mixed checksumming --- one cool idea would
> > be for ANALYZE to report how many of the pages it saw were checksummed.
> > Yeah, crazy, but it might be enough.
>
> Well, I didn't say VACUUM FULL was the only clean way of knowing
> whether every block is checksummed, its a very intrusive way.
>
> If you want a fast upgrade with pg_upgrade, rewriting every block is
> not really a grand plan, but if you want it...
>
> If we did that, I think I would prefer to do it with these commands
>
> VACUUM ENABLE CHECKSUM; //whole database only
> VACUUM DISABLE CHECKSUM;
>
> rather than use a GUC. We can then add an option to pg_upgrade.
>
> That way, we scan whole database, adding checksums and then record it
> in pg_database
>
> When we remove it, we do same thing in reverse then record it.
>
> So there's no worries about turning on/off GUCs and we know for
> certain where our towel is.

Yes, that would work, but I suspect most users are going to want to
enable checksums when they are seeing some odd behavior and want to test
the hardware. Requiring them to rewrite the database to do that is
making the feature less useful, and once they have the problem fixed,
they might want to turn it off again.

Now, one argument is that they could enable checksums, see no checksum
errors, but still be getting checksum failures from pages that were
written before checksum was enabled. I think we just need to document
that checksum only works for writes performed _after_ the feature is
enabled.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +