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 1r7YxF-005pG5-Gz for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Nov 2023 10:35:05 +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 1r7YxE-00CchY-8k for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Nov 2023 10:35:04 +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 1r7YxD-00CchQ-Vb for pgsql-hackers@lists.postgresql.org; Mon, 27 Nov 2023 10:35:03 +0000 Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1r7YxA-008lsf-NB for pgsql-hackers@postgresql.org; Mon, 27 Nov 2023 10:35:02 +0000 Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-54b18c9b21bso2329678a12.0 for ; Mon, 27 Nov 2023 02:35:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1701081298; x=1701686098; darn=postgresql.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=1h4MciTSY/YuajyyKIBCWTIkXkQZeG8qmg4+8CKBgCw=; b=mWBlCAhpRpRig8X3fjFpwRAT0GzG2HDMEJztJSfonzpTYzyZPVvLTJVea5rtWFqq2y PA3hc/vypTRiE7LB8B3nN7AoYQk3XMZnNqQH0eO0cyczOyyTKQ9FDSybA9HwcJsWV3nk 8MrR1rHV8AXht0Cck03H0w4Pa3JEqUVm6WufHTLbNj4Byy17ymbeIu6VRyEUY09vNKc8 fRzztshDHg/HwJoy4UOUVwdbRfOu24P4RydVfRAN7CZncQXl5fxG31kyAfdN2bSVf8BP m4U8iLakNYtLs+0cPUHWyNw4YyJ1dDmFKMlcx6SKUigURMwGnTTT0ZdLDk2enjT0Lyki 7pkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701081298; x=1701686098; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1h4MciTSY/YuajyyKIBCWTIkXkQZeG8qmg4+8CKBgCw=; b=bZbgTNpEBRq8rMYTr+LonLk7aBomh93EMRB5xzk7BBoigkWoiI2rjdETfqfWoLm3gM M8I61rv9z3vtuuEyk1fzg6sG3zqjeHRllaOW7b7CohPLeKtc9lhq7++dBFuTUDVTfGUd 1dCBk364rAlKn+K1Ml9Y2Ky+5kr8kIo0ZmCejmLQGVzk1I+pxZC1Ym60VoaHjOPfhEQ/ y9vlsc9/KZpZ4XiAGl+JSzLUzjC78r5wUOVacNPfAJs+v8AQk2Ee/jA4RJA9Ye/15HZH Ls2w/s4/pN0XMPoAG1jeQn6tCsjMzc+9HDq8m9SijlHYwsUyOI2vjeygD1ZsUJZQnO8G gQdg== X-Gm-Message-State: AOJu0Yw+Rws03tvaGVcZiww/MmPMHY+X8Y6108cr2NFS5air6gSq3V4Y F9uFqTqdq3DFSln91mQ5L8t0pw== X-Google-Smtp-Source: AGHT+IHk/Bgg3nIN9Ct3tp1ZruHkwN8ljdMShkvMLr9ORCylzU9QbRWQneDGaBls8/401cZr29eSAQ== X-Received: by 2002:a17:906:1281:b0:9dd:7133:881 with SMTP id k1-20020a170906128100b009dd71330881mr7517646ejb.40.1701081297821; Mon, 27 Nov 2023 02:34:57 -0800 (PST) Received: from [10.137.0.17] (ip-86-49-229-30.bb.vodafone.cz. [86.49.229.30]) by smtp.gmail.com with ESMTPSA id q22-20020a1709064c9600b009ae69c303aasm5503048eju.137.2023.11.27.02.34.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Nov 2023 02:34:57 -0800 (PST) Message-ID: <4b436ddb-39a5-fad5-5486-f8f971dcaaf6@enterprisedb.com> Date: Mon, 27 Nov 2023 11:34:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: brininsert optimization opportunity To: Richard Guo , Soumyadeep Chakraborty Cc: Matthias van de Meent , Alvaro Herrera , pgsql-hackers , Ashwin Agrawal References: <20230704112358.bkm6r3fxp275m4lu@alvherre.pgsql> <11f78627-a934-1f8b-084e-21ed95f2564c@enterprisedb.com> <35e7be37-0d35-d8ea-a4d5-eff84aefcc39@enterprisedb.com> <1d68ef1d-41c5-7159-c6c0-b44dad4e3148@enterprisedb.com> <12d42882-7860-9b46-7572-3b2fae6c916f@enterprisedb.com> Content-Language: en-US From: Tomas Vondra In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 11/27/23 08:37, Richard Guo wrote: > > On Mon, Nov 27, 2023 at 1:53 PM Soumyadeep Chakraborty > > wrote: > > On Sun, Nov 26, 2023 at 9:28 PM Richard Guo > wrote: > > It seems that we have an oversight in this commit.  If there is no > tuple > > that has been inserted, we wouldn't have an available insert state in > > the clean up phase.  So the Assert in brininsertcleanup() is not > always > > right.  For example: > > > > regression=# update brin_summarize set value = brin_summarize.value; > > server closed the connection unexpectedly > > I wasn't able to repro the issue on > 86b64bafc19c4c60136a4038d2a8d1e6eecc59f2. > with UPDATE/INSERT: > > This could be because since c5b7ba4e67aeb5d6f824b74f94114d99ed6e42b7, > we have moved ExecOpenIndices() > from ExecInitModifyTable() to ExecInsert(). Since we never open the > indices if nothing is > inserted, we would never attempt to close them with ExecCloseIndices() > while the ii_AmCache > is NULL (which is what causes this assertion failure). > > > AFAICS we would also open the indices from ExecUpdate().  So if we > update the table in a way that no new tuples are inserted, we will have > this issue.  As I showed previously, the query below crashes for me on > latest master (dc9f8a7983). > > regression=# update brin_summarize set value = brin_summarize.value; > server closed the connection unexpectedly > > There are other code paths that call ExecOpenIndices(), such as > ExecMerge(). I believe it's not hard to create queries that trigger > this Assert for those cases. > FWIW I can readily reproduce it like this: drop table t; create table t (a int); insert into t values (1); create index on t using brin (a); update t set a = a; I however wonder if maybe we should do the check in index_insert_cleanup and not in the AM callback. That seems simpler / better, because the AM callbacks then can't make this mistake. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company