Message-ID: <830004cb0a514d803d13ab9abcfa15fbae365748.camel@cybertec.at>
Subject: Re: data checksums
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Christophe Pettus <xof@thebuild.com>, bruno vieira da silva
	 <brunogiovs@gmail.com>
Cc: pgsql-general@lists.postgresql.org
Date: Wed, 07 Aug 2024 04:45:44 +0200
In-Reply-To: <15AB8DDB-7D4B-4272-801F-F5DD84E829E6@thebuild.com>
References: 
	<CAB+Nuk8y88kvoRHsfN2Pjed9o_iM+9FbveU=4P8G0EQbzFP+qw@mail.gmail.com>
	 <15AB8DDB-7D4B-4272-801F-F5DD84E829E6@thebuild.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.3 (3.52.3-1.fc40) 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/830004cb0a514d803d13ab9abcfa15fbae365748.camel%40cybertec.at>
Precedence: bulk

On Tue, 2024-08-06 at 09:29 -0700, Christophe Pettus wrote:
>=20
> > On Aug 6, 2024, at 08:11, bruno vieira da silva <brunogiovs@gmail.com> =
wrote:
> >=20
> > so my question is why data checksums aren't enabled by default on pg?
>=20
> At this point, mostly historical reasons.  They're also superfluous if yo=
ur underlying
> file system or storage hardware does storage-level corruption checks (whi=
ch most don't).

I am surprised by that.  Would you say that most storage systems will happi=
ly give you a
garbage block if there was a hardware problem somewhere?

> > the pg doc=20
> > mentions a considerable performance penality, how considerable it is?
>=20
> That line is probably somewhat out of date at this point.  We haven't see=
n 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 significa=
ntly increase
the amount of WAL written.

Yours,
Laurenz Albe