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 1phkOP-0003Zg-3Q for pgsql-bugs@arkaria.postgresql.org; Thu, 30 Mar 2023 05:00:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1phkOO-0005lJ-1d for pgsql-bugs@arkaria.postgresql.org; Thu, 30 Mar 2023 05: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 1phkON-0005lA-P1 for pgsql-bugs@lists.postgresql.org; Thu, 30 Mar 2023 05:00:07 +0000 Received: from mail-lf1-x12f.google.com ([2a00:1450:4864:20::12f]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1phkOK-0006po-My for pgsql-bugs@lists.postgresql.org; Thu, 30 Mar 2023 05:00:06 +0000 Received: by mail-lf1-x12f.google.com with SMTP id k37so23037047lfv.0 for ; Wed, 29 Mar 2023 22:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680152403; 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=bRnwC8OkBiAb6Uwv9zBcLXdppe+IL2y9TAwMRTO1hTY=; b=Tb9nHOAjR/u4s9reHRkN9USUlXSo4dJqJ8htNGHHQLu3PdvIgqLi2L3WmlUp+n2cIh jSzC4rA9bEIhIMzGiCZoRvdMKNpeS6gsg+86TxOi9kGcS0rHpcx3k8eThyguRr0mky4A j7GESZxGJ3MsFTGfDXG9irqhZ2BWp7LZMsPag8d3W6XkoIzgiYMkmSiKxRbLE2beFZRw obblyXg49UKnD9tQIIkQqNG3upmmG/9Oa3aj4uelepWqshiw5Xm96pLBfPu7mlphPmyj qTjtGaPH02LcxPUR77Ck0j9V7lsai9gcrFwWWhtLDPOLIZZqsCWFySsVWF5bNQwu556y 9cLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680152403; 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=bRnwC8OkBiAb6Uwv9zBcLXdppe+IL2y9TAwMRTO1hTY=; b=tbF1NImJk65AQQkaP/5oYPzDkqdokfkBUD3zaCOJ6gSHDrht5ir7cIf9BMwLTkRutP W2LqEBzQrCT+XXGcpZ3R95kRVoI3SxHKwzctOmByKBZuI2noeGWxu58a9bagz3KBh3Az U0QUFRvvUY2UAsQ8I9kSLrEHAywe20N589xOTDYV74sUO2bpRQq6t3iLYiPWuPUAvcWF Ux9GJMAlMlapwWdqstk63f6Es52KwPu2eAi4j/smfE4vw6mQtwFTWsEutdlCt+dcIi9d TOX1qMeOB8cUOoAMPcc5xfpBN8ZCPIwUb9o8fnX1yo8TNUx4fBA4kyqLYg5oB2Ch+uy9 piYg== X-Gm-Message-State: AAQBX9d/8+fetVJ/KopH7N+h7OSPZPWHjkxIx3tsXuMzowJXzLw03lES Ot3PQW7B+6I4r22EgwEOrZg= X-Google-Smtp-Source: AKy350bHJM9IxOj0zMJkE0CRonLV4W2L1nPCw6kjYSkbIrBZ1dcbG/1Fg48YFkuEpENq8mNhDSAHLw== X-Received: by 2002:a19:ac0c:0:b0:4e8:49ff:8dfe with SMTP id g12-20020a19ac0c000000b004e849ff8dfemr5972495lfc.61.1680152402701; Wed, 29 Mar 2023 22:00:02 -0700 (PDT) Received: from [1.0.0.7] ([178.155.28.197]) by smtp.gmail.com with ESMTPSA id 21-20020ac24855000000b004d5a720e689sm5758327lfy.126.2023.03.29.22.00.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Mar 2023 22:00:02 -0700 (PDT) Message-ID: Date: Thu, 30 Mar 2023 08: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 #16329: Valgrind detects an invalid read when building a gist index with buffering Content-Language: en-US To: Tom Lane , Pavel Borisov Cc: pgsql-bugs@lists.postgresql.org, kyzevan23@mail.ru References: <16329-7a6aa9b6fa1118a1@postgresql.org> <3dda6945-c147-5afc-7720-38ec6848dafa@gmail.com> <10261.1588705157@sss.pgh.pa.us> <3990135.1680104273@sss.pgh.pa.us> <4095379.1680128498@sss.pgh.pa.us> From: Alexander Lakhin In-Reply-To: <4095379.1680128498@sss.pgh.pa.us> 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 30.03.2023 01:21, Tom Lane wrote: > > The question is whether it's worth the extra test cycles forevermore. > On my machine, the time for the gist test script goes from ~400ms to > ~600ms. That's still less than some of the concurrent scripts (brin, > privileges, and join_hash all take more than that for me), so maybe > it's fine. But it seems like a lot for a change that doesn't move the > raw code coverage results by even one line. > > Thoughts? I would say that providing the behavior coverage is the next thing to do after the code coverage reached 100%.  I can easily imagine bugs hiding in a fully covered code (#17858 is the recent example). As to that concrete place, I would incline to improve the test while it stays in line with other tests, but I lack a whole picture of the gist testing. It doesn't seem to me that the regress/sql/gist.sql is too comprehensive. I've just looked at the scan-build's results and found 9 warnings related to gist. A quick glance at the code confirms that there are indeed interesting cases, which are not exercised for now (e.g., call gistRelocateBuildBuffersOnSplit() with IndexRelationGetNumberOfKeyAttributes(r) > 1). So if I could prove that 2-3 of them are really bugs during the next week, maybe then assess that test change alongside with others (if any). (Maybe we'll want to build that index over different columns, for example.) Best regards, Alexander