| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Enabling Checksums |
| Date: | 2012-11-13 20:27:47 |
| Message-ID: | CA+TgmoYkza5fTgYC5N2eZhLM6vMRCM-q3a4R=_Z8fP33tF=ddA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Nov 11, 2012 at 5:52 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> Per-database does sound easier than per-table. I'd have to think about
> how that would affect shared catalogs though.
>
> For now, I'm leaning toward an offline utility to turn checksums on or
> off, called pg_checksums. It could do so lazily (just flip a switch to
> "enabling" in pg_control), or it could do so eagerly and turn it into a
> fully-protected instance.
>
> For the first patch, it might just be an initdb-time option for
> simplicity.
It'd be pretty easy to write a pg_checksums utilitys to turn checksums
on/off on a database that is shut down, since the hard part of all of
this is to change the state while the database is running. But I
think even that doesn't need to be part of the first patch. A small
patch that gets committed is better than a big one that doesn't.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Browne | 2012-11-13 20:29:06 | Re: Proof of concept: standalone backend with full FE/BE protocol |
| Previous Message | Tom Lane | 2012-11-13 20:21:09 | Re: Memory leaks in record_out and record_send |