| From: | Greg Smith <greg(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
| Cc: | Daniel Farina <daniel(at)heroku(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Enabling Checksums |
| Date: | 2013-03-04 04:19:44 |
| Message-ID: | 513420E0.2060005@2ndQuadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 3/3/13 10:52 PM, Craig Ringer wrote:
> I also suspect that at least in the first release it might be desirable
> to have an option that essentially says "something's gone horribly wrong
> and we no longer want to check or write checksums, we want a
> non-checksummed DB that can still read our data from before we turned
> checksumming off".
I see that as being something that involves disabling the cluster-wide
flag that turns checksumming on, the one that is reported by
pg_controldata. I think it would have to be a one-way, system down kind
of change, which I think is fair given the ugly (but feasible) situation
you're describing. It would need to be something stronger than a GUC.
Once you start writing out pages without checksums, you're back into the
fuzzy state where some pages have them, others don't, and there's no
good way to deal with that yet.
--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2013-03-04 04:23:13 | Re: Enabling Checksums |
| Previous Message | Craig Ringer | 2013-03-04 04:15:24 | Re: LIBPQ Implementation Requiring BYTEA Data |