From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org, "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [HACKERS] wal_checksum = on (default) | off |
Date: | 2007-01-04 17:13:57 |
Message-ID: | 18471.1167930837@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> On Thu, 2007-01-04 at 11:09 -0500, Tom Lane wrote:
>> "It works most of the time" doesn't exactly satisfy me.
> It seemed safer to allow a very rare error through to the next level of
> error checking rather than to close the door so tight that recovery
> would not be possible in a very rare case.
If a DBA is turning checksums off at all, he's already bought into the
assumption that he's prepared to recover from backups. What you don't
seem to get here is that this "feature" is pretty darn questionable in
the first place, and for it to have a side effect of poking a hole in
the system's reliability even when it's off is more than enough to get
it rejected outright. It's just a No Sale.
I don't believe that the hole is real small, either, as
overwrite-with-zeroes is not exactly an unheard-of failure mode for
filesystems.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-01-04 17:20:32 | ReadyForQuery() |
Previous Message | Tom Lane | 2007-01-04 17:07:03 | Re: [HACKERS] wal_checksum = on (default) | off |
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-01-04 17:53:44 | Re: [HACKERS] wal_checksum = on (default) | off |
Previous Message | Tom Lane | 2007-01-04 17:07:03 | Re: [HACKERS] wal_checksum = on (default) | off |