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 1pe9V4-0006e2-AJ for pgsql-bugs@arkaria.postgresql.org; Mon, 20 Mar 2023 07:00:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pe9V2-0004NM-Rn for pgsql-bugs@arkaria.postgresql.org; Mon, 20 Mar 2023 07:00:08 +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 1pe9V2-0004ND-Ha for pgsql-bugs@lists.postgresql.org; Mon, 20 Mar 2023 07:00:08 +0000 Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pe9Uz-0006fs-MM for pgsql-bugs@lists.postgresql.org; Mon, 20 Mar 2023 07:00:07 +0000 Received: by mail-lf1-x131.google.com with SMTP id q16so2759628lfe.10 for ; Mon, 20 Mar 2023 00:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679295603; h=content-transfer-encoding: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=H2VlFGhFkUzbnOQvfLvp86H53OHaltQVVMvEk3bDmSE=; b=HlTZ9zKvuisyDKEgoYyvpO+1zUZeSVyeY9ugQgnnUTL0rXWdmGOCLlbuiUCbd/pAQg 4G8rR/NYl0YlEe9U4l2GQQxxUj9WQwy3J7f/BoyO/CNV+4Egt5blsfec451C1kQeNc75 I+rqvjbSSzQ5ZEKXUU5MoyKOTloXsfS9LuQGCLLj2kTQ2Pg+dCgxyJySb3Ss/JDdLn1L gcActAQepQ+RMZBk3N0qDcdFXStAfvPWsUxRZooJr1sMykG5VX7VMYG+hzhOyJ8T/ryC qmfTEC9qkM4IbBSInlRmwWgzesSiEH//EV1m9WLBIeDY8Sk/yGFTHseth+UkHRZpaMrh 7OxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679295603; h=content-transfer-encoding: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=H2VlFGhFkUzbnOQvfLvp86H53OHaltQVVMvEk3bDmSE=; b=59jSVLUYM46xjXjvqKor5xNCymHqVh1YQvwWyrhl15+Zmg9qK30Yv4k+WYZitrJWSw OZJX/qcnLJGiHT8aX3hIx3+YT9B/Nm34bmAREA1dA9jdyHq/DeN9HYrzj8kNIyQ8J8pz doEotPDRXBSuKBKd5D8x6RdJN2gfvkMN+wTL78YrbqJ85D7opKf6nV2LFfYqqzKFSrzh /LTni+cGy0UtTYgmAjo/ouILdjdp76IGNQ1Ll0Bg0ewosST4hQPrT9v7uh8aLDvhw/c3 ZASvAGvbRfG62KuSh44f7bHemMwd7GkcbCWgK+BVU0E4uVXRzziWV2RgSzzpV5jDGndQ A/lg== X-Gm-Message-State: AO0yUKV0yerOouaEzSWIYASVQtGYMdbv6y/7qL1SAsiwgvgpp20OwnYN UxrZTGHwWnygsqmKxwepPPo= X-Google-Smtp-Source: AK7set+ttyI9tsmS7kNaxVs2knpyrUp3q4G7A90oHN00D8EZ+Ve6W0tSDvezw4JpAin8KJJ8n0nkuQ== X-Received: by 2002:a19:740e:0:b0:4e9:bf52:7898 with SMTP id v14-20020a19740e000000b004e9bf527898mr912113lfe.37.1679295602891; Mon, 20 Mar 2023 00:00:02 -0700 (PDT) Received: from [1.0.0.7] ([178.155.5.7]) by smtp.gmail.com with ESMTPSA id n6-20020ac242c6000000b004e84896253asm1567620lfl.251.2023.03.20.00.00.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Mar 2023 00:00:02 -0700 (PDT) Message-ID: <365d1917-f5b7-ff20-2d0b-8d501cee5434@gmail.com> Date: Mon, 20 Mar 2023 10:00:00 +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: Alexander Korotkov , Tom Lane Cc: pgsql-bugs@lists.postgresql.org References: <17847-171232970bea406b@postgresql.org> <3966266.1678995315@sss.pgh.pa.us> From: Alexander Lakhin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, 19.03.2023 20:08, Alexander Korotkov wrote: > On Thu, Mar 16, 2023 at 10:35 PM Tom Lane wrote: >> What I'm inclined to do about this is add a restriction that the siglen >> value be a multiple of MAXALIGN. It doesn't look like the reloption >> mechanism has a way to specify that declaratively, but we could probably >> get close enough by just making LTREE_GET_SIGLEN throw an error if it's >> wrong. That's not ideal because you could probably get through making >> an empty index without hitting the error, but I don't offhand see a >> way to make it better. > Sorry for missing this. > > Please, note that there are infrastructure of reltoption validators. > I think this is the most appropriate place to check for alignment of > siglen. That works even for empty indexes. See the attached patch. Thanks for the fix! It works for me. Maybe it's worth to reflect this restriction in the documentation too?      gist_ltree_ops GiST opclass approximates a set of      path labels as a bitmap signature.  Its optional integer parameter      siglen determines the      signature length in bytes.  The default signature length is 8 bytes.      Valid values of signature length are between 1 and 2024 bytes. How about "The length must be a multiple of int alignment between 4 and 2024."? (There is a wording "int alignment (4 bytes on most machines)" in catalogs.sgml.) Also maybe change the error message a little: s/siglen value must be integer-alignment/siglen value must be integer-aligned/ or "int-aligned"? (this spelling can be found in src/) (There is also a detail message, that probably should be corrected too: DETAIL:  Valid values are between "1" and "2024". -> DETAIL:  Valid values are int-aligned positive integers less than 2024. ?) Best regards, Alexander