Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uyVgD-00921a-Ex for pgsql-general@arkaria.postgresql.org; Tue, 16 Sep 2025 13:25:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uyVgA-000O09-Ap for pgsql-general@arkaria.postgresql.org; Tue, 16 Sep 2025 13:25:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uyVg9-000O00-QE for pgsql-general@lists.postgresql.org; Tue, 16 Sep 2025 13:25:06 +0000 Received: from mail.postgrespro.ru ([93.174.132.70]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uyVg5-0018RV-22 for pgsql-general@lists.postgresql.org; Tue, 16 Sep 2025 13:25:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1758029100; bh=CMftcXHqsU+1+DLi9HpoX7p8YwHMtq96NIfwUfCH4ow=; h=Date:From:To:Cc:Subject:In-Reply-To:References:Message-ID:From; b=aQjRRzrhtaYT7FV35aOydya+EIcz/4SpCmK89qqwcN0gWQnzK52VRgzj2or/HRKoe PijRUt6oe0nqiGOi7UC+gnwFac36aC1xyacdbtkDGjzSasN/Aagth56t7T8qseVzc/ kwSCi2jX95sJmLaTi3gaZBVXmyikvuO5LMsqrHL3qswSMz334WBQmHFh8SYQv6MGCP vUBeLvC3C5ztLCVjzX3RAWl720ZLBGNA0YKQs37c0niSIUmzoSBsIJb2Hnk2tiORht bxlxc0GMwzvArcDkZ5cSaB14ZAgeZUbHhndkQGVhScrTTlPnwx0ZllZoaBoGzapkCW 7yJWfnbGFFnZA== Received: from mail.postgrespro.ru (webmail-slave-mstn.l.postgrespro.ru [192.168.2.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: v.popolitov@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id B72C760AD0; Tue, 16 Sep 2025 16:25:00 +0300 (MSK) MIME-Version: 1.0 Date: Tue, 16 Sep 2025 16:25:00 +0300 From: Vladlen Popolitov To: Pawel Kudzia Cc: pgsql-general@lists.postgresql.org Subject: Re: Silent data corruption in PostgreSQL 17 - how to detect it proactively? In-Reply-To: References: Message-ID: <20e5800983ca176d696f2f90ecc0a830@postgrespro.ru> X-Sender: v.popolitov@postgrespro.ru Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-KSMG-AntiPhishing: NotDetected X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 2.1.0.7854, bases: 2025/09/16 10:23:00 #27823558 X-KSMG-AntiVirus-Status: NotDetected, skipped X-KSMG-LinksScanning: not scanned, disabled by settings X-KSMG-Message-Action: skipped X-KSMG-Rule-ID: 1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Pawel Kudzia писал(а) 2025-09-14 15:47: > On Sun, Sep 14, 2025 at 12:35 PM Laurenz Albe > wrote: > > gdb stack trace for that process: > > #0 0x000055cb571ef444 in hash_search_with_hash_value () > #1 0x000055cb5706217a in BufTableLookup () Hi, Probably, it does not hang in function hash_search_with_hash_value(), probably you caught it in this function in that moment of the time. This function itself do finite work and returns, it is hard to harm it by wrong data. This function is called by code, that goes to leafs of the B+tree. If this code enters destroyed block, it goes to wrong blocks and behave unexpectedly. For example, it goes to block zero, that is not leaf block (meta-page of the index) and probably has a lot of zero. Btree code get new block address - 0 again, and again goes to block 0. You have two options: 1) enable checksums (that is highly recommended) and get error message immediately in case of failure, and restore database from backup (and probably consider the change of the provider) 2) continue with disabled checksums, get programs crashes and finally restore from backup. Checksum calculation takes ~0.5% of query time, it is not bottleneck in PostgreSQL. P.S. Databases have a lot of code, that rely on correctness of original data on the disk. It is impossible to to check every byte, is it correct or not. -- Best regards, Vladlen Popolitov.