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 1txRjq-009SvN-Fb for pgsql-bugs@arkaria.postgresql.org; Wed, 26 Mar 2025 14:28:14 +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 1txRjo-0049P1-FM for pgsql-bugs@arkaria.postgresql.org; Wed, 26 Mar 2025 14:28:12 +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 1txRjn-0049Ot-GI for pgsql-bugs@lists.postgresql.org; Wed, 26 Mar 2025 14:28:12 +0000 Received: from fhigh-a3-smtp.messagingengine.com ([103.168.172.154]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1txRjl-001Fc2-0g for pgsql-bugs@lists.postgresql.org; Wed, 26 Mar 2025 14:28:10 +0000 Received: from phl-compute-13.internal (phl-compute-13.phl.internal [10.202.2.53]) by mailfhigh.phl.internal (Postfix) with ESMTP id 9345F114015D; Wed, 26 Mar 2025 10:28:07 -0400 (EDT) Received: from phl-imap-09 ([10.202.2.99]) by phl-compute-13.internal (MEProxy); Wed, 26 Mar 2025 10:28:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eulerto.com; h= cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1742999287; x=1743085687; bh=bcvi7kPQNs WwiVQqIWRcVl4gE9UpCHhlYytgVvJLgOI=; b=TpvjmD1F3HvWVTxruikpIXHY3q balDDxHPGLAvwjujhpy5oBfm2fuI5Xg9v7piWzl4WWmSVOcEduCpZfaCeWPnxLd0 1708A9vitTWYEhCPRWPGSlPK+TJWPkbQM/ghXe4XQmBN1noNwytcjeQetGE13Hdq PyJ4D/Vx/IVR9SQQFeygN55O0sAbus83mBT3n0Kw6wF3NbiuzdSE8E9Z/mtT2BkN 1UpuU4BFupneQoPsKcIJiwY/g5FyGw1M0E2Romo11uO7LKAy3kpXDSHpFRzc3P0j HW6JAXnP5zkXs5LMiH4j9+TNOHkTmLcuf7cfn1BLrhZN0ZQGH6IqqFcnraFw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1742999287; x=1743085687; bh=bcvi7kPQNsWwiVQqIWRcVl4gE9UpCHhlYyt gVvJLgOI=; b=mgNXjuyuqClD6wdXcbLGGC5jXSyB1mmEht21yXEy+zxvtF0CbJD BDBZlTkGq23Y9qNQyEFik6kxgitOcL11dSRvfMH6w2SOKwCxIoBK+I+WubieHeNo Jw8CGcQ4e8iRs6vl3/81e7M5ywKcfXZS5JFoQBR8EA+YjVn1GknZa3ctgCb1SxJR PqxGeZtlpjyTClP6T7wDatuXzf+QgyFndTuyu9YvCiYmFvaiMAzG6E2QtAatMYF1 1FXF2nOGynzpoXk1wun3ekcJIXyedtehaO+JJJ2dbI0g/8v5z6A1bAGFSLPzf+r4 jRST2fhBctJxFbIoYliIgrq95Yy507PMExw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduieehjeejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefogg ffhffvkfgjfhfutgesrgdtreerredttdenucfhrhhomhepfdfguhhlvghrucfvrghvvghi rhgrfdcuoegvuhhlvghrsegvuhhlvghrthhordgtohhmqeenucggtffrrghtthgvrhhnpe fhtdduleeufeeltedutddukeekfeeugedvgfejteeggfffteeiffdugffgueffteenucff ohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepvghulhgvrhesvghulhgvrhhtohdrtgho mhdpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepph hgshhqlhdqsghughhssehlihhsthhsrdhpohhsthhgrhgvshhqlhdrohhrghdprhgtphht thhopegurghnqdgvlhhisehmrghilhdrrhhu X-ME-Proxy: Feedback-ID: i0c21471d:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 06520780068; Wed, 26 Mar 2025 10:28:06 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 X-ThreadId: Tf2adbf7b18fa87c5 Date: Wed, 26 Mar 2025 11:27:43 -0300 From: "Euler Taveira" To: dan-eli@mail.ru, pgsql-bugs@lists.postgresql.org Message-Id: In-Reply-To: <18868-76a65f10dd526ee5@postgresql.org> References: <18868-76a65f10dd526ee5@postgresql.org> Subject: Re: BUG #18868: /src/backend/optimizer/path/joinrels.c list_head can be NULL Content-Type: multipart/alternative; boundary=221130b8b6214b999e5662227959c847 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --221130b8b6214b999e5662227959c847 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, Mar 26, 2025, at 7:16 AM, PG Bug reporting form wrote: > Pointers, returned from function 'list_head' at joinrels.c:1527 and 1528, > may be NULL and is dereferenced at joinrels.c:1550 and 1551. joinrels.c: compute_partition_bounds(root, rel1, rel2, joinrel, parent_sjinfo, &parts1, &parts2); if (joinrel->partbounds_merged) { lcr1 = list_head(parts1); lcr2 = list_head(parts2); } Did you read compute_partition_bounds()? if (joinrel->partbounds_merged) { get_matching_part_pairs(root, joinrel, rel1, rel2, parts1, parts2); Assert(list_length(*parts1) == joinrel->nparts); Assert(list_length(*parts2) == joinrel->nparts); } parts1 and parts2 uses the same condition. I expect that if there is any bug related to pointer deference, the assert(s) should report. Do you have a test case that exposes this issue? -- Euler Taveira EDB https://www.enterprisedb.com/ --221130b8b6214b999e5662227959c847 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Wed, Mar 26,= 2025, at 7:16 AM, PG Bug reporting form wrote:
Pointers, returned from function 'l= ist_head' at joinrels.c:1527 and 1528,
may be NULL and is = dereferenced at joinrels.c:1550 and 1551.
joinrels.c:

    comp= ute_partition_bounds(root, rel1, rel2, joinrel, parent_sjinfo,
=
           &= nbsp;           &= nbsp;     &parts1, &parts2);

    if (joinrel->partbounds_merged)<= br style=3D"max-width:100%;height:auto;">
    {=     
=
        lcr1 =3D list_head(parts= 1);
  &nbs= p;     lcr2 =3D list_head(parts2);
    }   = ; 

Did you read compute_partition_bounds()?

        if (joinrel->partbounds_m= erged)
        {
    &n= bsp;       get_matching_part_pairs(root, j= oinrel, rel1, rel2,
=             =             =             parts= 1, parts2);
 &n= bsp;          Assert(list_l= ength(*parts1) =3D=3D joinrel->nparts);
        &= nbsp;   Assert(list_length(*parts2) =3D=3D joinrel->nparts)= ;
   =      }

parts1 and parts2 uses the same condition. I expec= t that if there is any bug
related to pointer deference, t= he assert(s) should report. Do you have a test
case that exposes this issue?


--
Euler Taveira
EDB   https://www.enterprisedb.com/=

--221130b8b6214b999e5662227959c847--