| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Checksums, state of play |
| Date: | 2012-03-06 16:50:53 |
| Message-ID: | CA+U5nMLD9LTdGEqq8OHpqArEDv1_kt8HnO5E61EkS678k77SmA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Mar 6, 2012 at 4:06 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Tue, Mar 6, 2012 at 3:31 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
>> I'll keep an open mind for now about database/table level. I'm not
>> sure how possible/desirable each is.
>
> Table level sounds great, but how will it work with recovery? We don't
> have a relcache in Startup process.
>
> So either database or tablespace level seems doable.
Even db or ts level is problematic.
Options
(1) Recovery ignores checksums until db in consistent state
(2) Recovery ignores checksums until all databases are enabled, when
we set flag in pg_control
(3) Recovery checks blocks marked as having a checksum, no matter the
overall state
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2012-03-06 17:00:25 | Re: Checksums, state of play |
| Previous Message | Robert Haas | 2012-03-06 16:42:17 | Re: Checksums, state of play |