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
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 |