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.96) (envelope-from ) id 1w4unu-002gfr-1n for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Mar 2026 05:59:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w4unt-004LXs-0B for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Mar 2026 05:59:49 +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.96) (envelope-from ) id 1w4uns-004LXk-2G for pgsql-hackers@lists.postgresql.org; Tue, 24 Mar 2026 05:59:49 +0000 Received: from mail-ot1-x32a.google.com ([2607:f8b0:4864:20::32a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w4unp-00000000pAS-1rHx for pgsql-hackers@postgresql.org; Tue, 24 Mar 2026 05:59:48 +0000 Received: by mail-ot1-x32a.google.com with SMTP id 46e09a7af769-7d7f92bde91so1936879a34.1 for ; Mon, 23 Mar 2026 22:59:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774331982; cv=none; d=google.com; s=arc-20240605; b=do+7RaYb2qtPac7fFl5wJmvBSrNI3YKkmniGa7W7wtpjxLr/jnf3niCs+pUOykUvvQ DhwlrPq/pJrlzAHUjWzyJIv55Vs41wB90zq2G4xmGyYuo48qo7ezV+sdV8R9t1Xl3TKg SxHvueFQ5mVjgjlYGqAVYyOySf92oeXGAxWBz2pM8xAJx3lvf0a1sVdPSm2wZ3Vit8al w51zD4apDVhFEXlw+YumEjEx4ZhPINrCgoAzdMo191JtR7ddAYAOkv6TW7FJsPgiyiOZ jTT80dlujd3geoHEs4cGRZ/ixCpZOr71h0yRHo1pMRsu+yMxrtRjChUqH146lB7J3bL8 blpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=msMVkFlO0d9lzylvN9P8De0vGYah7FZejDY4sKp8as4=; fh=csmHZUc8nA08NviEbxuI5m3dv7Rr7YuiTc773m8NcVg=; b=aZ8lNVv0SD7PJXj3uDSvyENPEfpw6kyyaykA3lHg0QruQZjPy5Tsl/dJDx/iUdtBKI 08nUtzRKSC6PcKWhZXzf4+a4LqGSLVWXKs1aPFOL2lEMNVwkISy5PhPWzCjiyOqSnmfG 18WWFEdP0HieAgDYL4z5EibJEwwGJCs1lfH9cgu74Aqnu1JmBwxCeYKHJPVwBWt36qEW WUTWcENhj3c1ZyuyNzeM616iCXlQ8bZmaGQhkbWoXa+8RbGwfnGZCXf0L8EHa0HTpPJW t786mUXP5MFmFAW0FVWzqYgiSTQG0EkDx5cdpIt83gmeeJncQpUOJJzHghv3WdnWFGE+ IzOQ==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1774331982; x=1774936782; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=msMVkFlO0d9lzylvN9P8De0vGYah7FZejDY4sKp8as4=; b=AH64Jq9bQOjlTRcIozlKbfjVr748ohCMq+lG+7NcL0+jiyiUHc6dtsQmYsQVFkElBi kYsQ9vtgjN/ZxIepup2wOmazrZypcydPaXnafAI/VxhknepNwfDuTHTmA8a+vNmR4BF+ DroQ7ZbDmiKbRBVjx41l9+YcNW6v/4faxs/RQq+cl8/f3bWjtxnVmMILs7/qQ+rvKWO+ MMcM9foKTbfWstvJ2KSQCtsGnyissjR+woxuy41k+NFdyIdbUQMFz1VOxB0Q2pVvEvKh S/wK41wwv5MGjcB0buqTd7HCDF55agrZgc5RFvo7LjKPVe74d4ABokzrAFELll9AX4zr U8hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774331982; x=1774936782; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=msMVkFlO0d9lzylvN9P8De0vGYah7FZejDY4sKp8as4=; b=gFVBMpcWN+2a6fOapztN9fM9eMdGvTSDD3xdL2nt/h5vbw3zELauSnEBIDZ3nmRUP/ VFkN4OeCdAkDi5DRR/+T3Ono8jjsWKTT6HWXFywxq1Hf3CLQmQGFMPeuFTj4Fl9YGSOO /bRR/u9ut5eDErqJTomxushEhUHaG3pyBGXv1RIl03rD+pboa//NVzbnRmnjB6yLl4Df ihgqXwd4ZgwOig+8PWqtjBUiHTkhZDhg85Va+gvm4MmdIIKpfceD2kjpCtx5ZJR7rsTN rWNKnZk8I/Pdp3QoB3i3oY55j6ZZKhf0Sw+xwRNFEnZu0hKtXFoHKjTOUgfgwIsmxczW 6kgw== X-Forwarded-Encrypted: i=1; AJvYcCWOVAdjJKDXCszKtBLdq9YaVFfh+atvKbGo3WZ1pOV39IBNYIMxt8k8fNjdCar4hABrI7UhfuteqTay2zmf@postgresql.org X-Gm-Message-State: AOJu0Yxdeud6vBUtHaCdQHCEgTfNLwvEystgqYeW6RO/kCN7V3G7O916 ukDUNQKAhhFPzxnJTmpkD24keeRBkemiq7jHkfVlOC9vlH1ab0TY41MsST+bRzLOSPlMLvqJG1a SiYKf6KwS1Bnv0ZxQZOZrRVzJY9yWNAgvt4tlB+zk X-Gm-Gg: ATEYQzzMxWNMQII4bam4ABBF+Xu7BfIOpUK7W/NNOCgsZuHQo4rHYHZJZDfu5k2S3C7 lFt+YPh/1HkNN8SuBO0CC3wkbs+bZW5TZcD5WYgWnvbpxdvHSHm8TjAmWTCSNMtaixQIR762jtv mzlqi+AMzx25Drnw5hde3YaQUirOZAHvYp6c6PXcTDVDIB1sQFdUAnaLGJcpIfkyqCQWdesSCO3 3U88zVjTOffVCul7Rh48aSfrdmijTVJuZ1nevjqG0moj/As/DZpe49k5J7nArkSOIcR2HyNylGk PXMO+OzB+w== X-Received: by 2002:a05:6808:e881:20b0:467:1941:1f0a with SMTP id 5614622812f47-467e5d7686fmr7309490b6e.11.1774331982675; Mon, 23 Mar 2026 22:59:42 -0700 (PDT) MIME-Version: 1.0 References: <3007317.1765210195@sss.pgh.pa.us> In-Reply-To: From: Nishant Sharma Date: Tue, 24 Mar 2026 11:29:31 +0530 X-Gm-Features: AQROBzD5jOJ653bT5v2lc3ORM7e4dooKKV-biOZpR6URmNBfvR7IgAl_RUPG_w8 Message-ID: Subject: Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL To: Mahendra Singh Thalor Cc: Shruthi Gowda , Fujii Masao , Tom Lane , PostgreSQL Development Content-Type: multipart/alternative; boundary="0000000000008aa2db064dbedb83" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000008aa2db064dbedb83 Content-Type: text/plain; charset="UTF-8" Here are some review comments on v3 patch:- 1. Change in descriptor.c file - In my opinion, we can use `if(conn)` with ecpg_raise, like other occurrence of ecpg_get_connection() call check in this file, and not using ecpg_init(). Three reasons: a) Consistency in checking conn after ecpg_get_connection() call in this file with if check. b) We don't need to remove 'ecpg_init_sqlca(sqlca);' line due to call to ecpg_init(). c) #2 comment below. 2. If you agree with #1, then I see many other reasons for which ECPGget_desc() returns and we can avoid ecpg_get_connection() call at top of that function for those reasons and keep the check at the required location only instead of moving at top of the function. 3. I see there is one more location of ecpg_get_connection() call where there is no check of NULL conn. In function ecpg_freeStmtCacheEntry() of file prepare.c? I understand it's not required for a call in ecpg_auto_prepare(), as the caller already validated that connection string. But I think, conn in ecpg_freeStmtCacheEntry() is different from the one that was validated. 4. +1 to Mahindra, new test cases specific to the crash required for this change? Regards, Nishant Sharma, EDB, Pune. https://www.enterprisedb.com/ --0000000000008aa2db064dbedb83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

  • =

    Change in descriptor.c file - In my opinion, we can use `if(conn)` with ecpg_raise, like other occurrence of ecpg_get_connection() call check in this file, and not using ecpg_init(). Three reasons: a) Consistency in checking conn after ecpg_get_connection() call in this file with if check. b) We don't need to remove 'ecpg_init_sqlca(sqlca);' line due to call to ecpg_init(). c) #2 comment below.

  • If you agree with #1, then I see many other reasons= for which ECPGget_desc() returns and we can avoid ecpg_get_connection() call at top of that function for those reasons and keep the check at the required location only instead of moving at top of the function.

  • I see there is one more location of ecpg_get_connection() call where there is no check of NULL conn. In function ecpg_freeStmtCacheEntry() of file prepare.c? I understand it's not required for a call in ecpg_auto_prepare(), as the caller already validated that connection string. But I think, conn in ecpg_freeStmtCacheEntry() is different from the one that was validated.

  • +1 to Mahindra, new test cases specific to the crash required for this change?


    • <= span style=3D"font-size:14px">
    = Regards,
    Nishant Sharma,
    <= span style=3D"font-size:14px">EDB, Pune.
    --0000000000008aa2db064dbedb83--