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 1s1rIV-00FSsL-C9 for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Apr 2024 17:29:43 +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 1s1rIQ-007QSS-U8 for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Apr 2024 17:29:39 +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 1s1rIQ-007QSJ-KB for pgsql-hackers@lists.postgresql.org; Tue, 30 Apr 2024 17:29:39 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s1rIO-000sf0-Vx for pgsql-hackers@lists.postgresql.org; Tue, 30 Apr 2024 17:29:38 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 43UHTWlY1696558; Tue, 30 Apr 2024 13:29:32 -0400 From: Tom Lane To: Alexander Korotkov cc: "Guo, Adam" , "pgsql-hackers@lists.postgresql.org" Subject: Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation In-reply-to: References: <3335675.1713884256@sss.pgh.pa.us> <1685377.1714496091@sss.pgh.pa.us> Comments: In-reply-to Alexander Korotkov message dated "Tue, 30 Apr 2024 20:02:04 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1696556.1714498172.1@sss.pgh.pa.us> Date: Tue, 30 Apr 2024 13:29:32 -0400 Message-ID: <1696557.1714498172@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Alexander Korotkov writes: > I agree that storing char signedness might seem weird. But it appears > that we already store indexes that depend on char signedness. So, > it's effectively property of bits-on-disk even though it affects > indirectly. Then I see two options to make the picture consistent. > 1) Assume that char signedness is somehow a property of bits-on-disk > even though it's weird. Then pg_trgm indexes are correct, but we need > to store char signedness in pg_control. > 2) Assume that char signedness is not a property of bits-on-disk. > Then pg_trgm indexes are buggy and need to be fixed. > What do you think? The problem with option (2) is the assumption that pg_trgm's behavior is the only bug of this kind, either now or in the future. I think that's just about an impossible standard to meet, because there's no realistic way to test whether char signedness is affecting things. (Sure, you can compare results across platforms, but maybe you just didn't test the right case.) Also, the bigger picture here is the seeming assumption that "if we change pg_trgm then it will be safe to replicate from x86 to arm". I don't believe that that's a good idea and I'm unwilling to promise that it will work, regardless of what we do about char signedness. That being the case, I don't want to invest a lot of effort in the signedness issue. Option (1) is clearly a small change with little if any risk of future breakage. Option (2) ... not so much. regards, tom lane