| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Christophe Pettus <xof(at)thebuild(dot)com>, bruno vieira da silva <brunogiovs(at)gmail(dot)com> |
| Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: data checksums |
| Date: | 2024-08-07 02:45:44 |
| Message-ID: | 830004cb0a514d803d13ab9abcfa15fbae365748.camel@cybertec.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Tue, 2024-08-06 at 09:29 -0700, Christophe Pettus wrote:
>
> > On Aug 6, 2024, at 08:11, bruno vieira da silva <brunogiovs(at)gmail(dot)com> wrote:
> >
> > so my question is why data checksums aren't enabled by default on pg?
>
> At this point, mostly historical reasons. They're also superfluous if your underlying
> file system or storage hardware does storage-level corruption checks (which most don't).
I am surprised by that. Would you say that most storage systems will happily give you a
garbage block if there was a hardware problem somewhere?
> > the pg doc
> > mentions a considerable performance penality, how considerable it is?
>
> That line is probably somewhat out of date at this point. We haven't seen a significant
> slowdown in enabling them on any modern hardware. I always turn them on, except on the
> type of filesystems/hardware mentioned above.
Turning data checksums on will write WAL for hint bits, which can significantly increase
the amount of WAL written.
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christophe Pettus | 2024-08-07 03:14:22 | Re: data checksums |
| Previous Message | Vamsi Chava | 2024-08-07 01:10:54 | Streaming replication issue post upgrade from version 11 to 14 on windows 2016 Server |