Re: Silent data corruption in PostgreSQL 17 - how to detect it proactively?

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Vladlen Popolitov <v(dot)popolitov(at)postgrespro(dot)ru>
Cc: Pawel Kudzia <kudzia(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Silent data corruption in PostgreSQL 17 - how to detect it proactively?
Date: 2025-09-16 16:41:38
Message-ID: CAHyXU0yCP4+XaYSxX3n5VaR9ym6cejDAvnGYUvqe4CECzLLmcA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Sep 16, 2025 at 7:25 AM Vladlen Popolitov <
v(dot)popolitov(at)postgrespro(dot)ru> wrote:

> Checksum calculation takes ~0.5% of query time, it is not bottleneck
> in PostgreSQL.

I consider checksums=on to be a mandatory setting. Often, these types of
things are not bugs in postgres itself, but bugs in storage, the underlying
operating system, or extensions. Checksums can and will protect you, and
may even bring you close to the thing causing the corruption. Given that
your replica is ok, this very much smells like a similar type of issue.

In a prior case, I was using pl/sh to load data to the database with
'copy', and for what I believe to be o/s issues, was getting corruption.
Enabling checksums completely addressed the source of the damage. Turn
them on!

merlin

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2025-09-16 17:44:04 Re: encoding problem while inictial copy in logical replication
Previous Message Adrian Klaver 2025-09-16 15:14:32 Re: EDB Windows Installer on Windows Server 2025