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 1rtdBr-00GJPB-At for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Apr 2024 00:48:51 +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 1rtdBq-00Ej25-4E for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Apr 2024 00:48:50 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rtdBp-00Ej1w-R4 for pgsql-hackers@lists.postgresql.org; Mon, 08 Apr 2024 00:48:49 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rtdBn-001jhu-G9 for pgsql-hackers@lists.postgresql.org; Mon, 08 Apr 2024 00:48:48 +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 4380mT8c3000248; Sun, 7 Apr 2024 20:48:29 -0400 From: Tom Lane To: Peter Geoghegan cc: Matthias van de Meent , PostgreSQL Hackers , Tomas Vondra , Jeff Davis , benoit , Alexander Korotkov Subject: Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan In-reply-to: References: Comments: In-reply-to Peter Geoghegan message dated "Fri, 20 Oct 2023 15:39:44 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3000246.1712537309.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sun, 07 Apr 2024 20:48:29 -0400 Message-ID: <3000247.1712537309@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Coverity pointed out something that looks like a potentially live problem in 5bf748b86: /srv/coverity/git/pgsql-git/postgresql/src/backend/access/nbtree/nbtutils.= c: 2950 in _bt_preprocess_keys() 2944 * need to make sure that we don't throw = away an array 2945 * scan key. _bt_compare_scankey_args ex= pects us to 2946 * always keep arrays (and discard non-ar= rays). 2947 */ 2948 Assert(j =3D=3D (BTEqualStrategyNumber - = 1)); 2949 Assert(xform[j].skey->sk_flags & SK_SEARC= HARRAY); >>> CID 1596256: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "array". 2950 Assert(xform[j].ikey =3D=3D array->scan_k= ey); 2951 Assert(!(cur->sk_flags & SK_SEARCHARRAY))= ; 2952 } 2953 } 2954 else if (j =3D=3D (BTEqualStrategyNumber - 1)) Above this there is an assertion Assert(!array || array->num_elems > 0); which certainly makes it look like array->scan_key could be a null-pointer dereference. regards, tom lane