Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pdQY2-00014j-N7 for pgsql-bugs@arkaria.postgresql.org; Sat, 18 Mar 2023 07:00:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pdQY0-0006vL-Uh for pgsql-bugs@arkaria.postgresql.org; Sat, 18 Mar 2023 07:00:12 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pdQY0-0006vC-KH for pgsql-bugs@lists.postgresql.org; Sat, 18 Mar 2023 07:00:12 +0000 Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pdQXu-0007N2-Cg for pgsql-bugs@lists.postgresql.org; Sat, 18 Mar 2023 07:00:11 +0000 Received: by mail-lj1-x235.google.com with SMTP id a32so7174484ljr.9 for ; Sat, 18 Mar 2023 00:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679122804; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=3Ee0EgJE+3Nukcua+nEy2zgp7fMrBU3N0ySdwC1Nf00=; b=cel+0zRISp9zh2wiQvNShlh3lRwlwSSnY7NGWEyj+Xb9CHK+f1o2oGKpy7cYhq8fM9 PZBQ14uOAqKlBgbJvs9zNFObeVwXq3zIfIYa88ns1/50XfFc1abSBZwmiKMOr6KDisYs 6sqkz0P1wiy3QO4kB8wena31F/Y2WaniU/ze1kfm93ih9YGCxawuyg1nnpfbRpUZO3bS qgM7T0gPG2Xy0sOS5h4BKx2/NDnRZl67DekIojjLVucK5ok8AF2+OtDr5wyyZ82tHY/2 golIc9vVAzN2EdOawYWL6+JgMpkNSFjzsjk5lAXnG/5rEXfXeJSpVXkBMmF/9NeiFkvk NlKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679122804; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=3Ee0EgJE+3Nukcua+nEy2zgp7fMrBU3N0ySdwC1Nf00=; b=GDHn1ngySmBX6ZQ9yhA82Pwhr+pvsA6lIMPQiO6oMIcTig4jw7XfMvE2WPARo8We0J O7G/cYIbawNEmwrCMtxQysmI9afRIioq4I4PGvNKJjTzDRo4wvYQ/0STpnTUtq4wr0QJ ySJAbPpuqJvmy8zUNanu8IkNtznph3VifLeaqNJ6+pB4+OO+Nosmd9f/S+iCLRn23LDq wzDQ7N3TXTozHyPp3EEchWibS3bR50UumYC5QLiG00tKaitSfY1uTHmiKBjR9NdlZzhX tSAMX3cQAH5Vtk41pjnaL2ke+gcj0h+6BkBqPgdy4WApOmu/3xdHW4m39xS/GLJ6M6cn xzWQ== X-Gm-Message-State: AO0yUKWlTPv6NxTnHNAh2XclGZLl/GeiNowMwaZVubEqPkVjkseaYXr0 P2rX4uC9JoGTGTC0M4vXXFE= X-Google-Smtp-Source: AK7set9Xy+b0E7y1pfPWvu1geRM9lzZ5tpcaSPU1JxpLK0ECW3RnG2LTPsoqXWYtnPfz79My/HXwaA== X-Received: by 2002:a2e:b5d5:0:b0:294:697a:d6a9 with SMTP id g21-20020a2eb5d5000000b00294697ad6a9mr3547832ljn.28.1679122803765; Sat, 18 Mar 2023 00:00:03 -0700 (PDT) Received: from [1.0.0.7] ([178.155.5.7]) by smtp.gmail.com with ESMTPSA id v21-20020a2e7a15000000b00295b1ad177csm722778ljc.68.2023.03.18.00.00.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Mar 2023 00:00:02 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------wcQ5sXIyHIjI0xKHo0R02Rlc" Message-ID: Date: Sat, 18 Mar 2023 10:00:01 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: BUG #17847: Unaligned memory access in ltree_gist Content-Language: en-US To: Tom Lane Cc: pgsql-bugs@lists.postgresql.org, Alexander Korotkov References: <17847-171232970bea406b@postgresql.org> <3966266.1678995315@sss.pgh.pa.us> From: Alexander Lakhin In-Reply-To: <3966266.1678995315@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------wcQ5sXIyHIjI0xKHo0R02Rlc Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 16.03.2023 22:35, Tom Lane wrote: > I wonder which other opclasses besides ltree have the same issue. I found no other similar places: siglen is also accepted by opclasses gist__intbig_ops, gist_hstore_ops, gist_trgm_ops, tsvector_ops, which implementations use functions _intbig_alloc, ghstore_alloc, gtrgm_alloc, gtsvector_alloc, and none of them adds siglen to a pointer. Quick testing confirms that. (gist__ltree_ops uses ltree_gist_alloc(), but the problematic branch "if (left) ..." not reached for gist__ltree_ops) Best regards, Alexander --------------wcQ5sXIyHIjI0xKHo0R02Rlc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
16.03.2023 22:35, Tom Lane wrote:
I wonder which other opclasses besides ltree have the same issue.

I found no other similar places: siglen is also accepted by opclasses
gist__intbig_ops, gist_hstore_ops, gist_trgm_ops, tsvector_ops,
which implementations use functions
_intbig_alloc, ghstore_alloc, gtrgm_alloc, gtsvector_alloc,
and none of them adds siglen to a pointer.
Quick testing confirms that.

(gist__ltree_ops uses ltree_gist_alloc(), but the problematic branch
"if (left) ..." not reached for gist__ltree_ops)

Best regards,
Alexander
--------------wcQ5sXIyHIjI0xKHo0R02Rlc--