On Thu, Jan 8, 2026 at 3:00 AM Shruthi Gowda <gowdashru@gmail.com> wrote: > > > On Mon, Dec 8, 2025 at 9:39 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> >> Shruthi Gowda <gowdashru@gmail.com> writes: >> > The ECPG application crashes with a segmentation fault when calling >> > specific deallocation or prepared statement functions without an >> > established database connection. This is caused by a missing NULL check on >> > the connection handle before attempting to access it. >> >> Hmm ... poking around, I see several other places that aren't checking >> the result of ecpg_get_connection. Shouldn't we tighten them all? >> >> regards, tom lane > > > I agree. I’ve reviewed all occurrences of ecpg_get_connection() and noted that, in most instances, it is followed by ecpg_init(), which validates the connection and returns immediately if the connection is NULL.
Why did you add this check instead of calling ecpg_init()? Wouldn't it be better and sufficient to use ecpg_init() to validate the connection?
+ con = ecpg_get_connection(connection_name); + if (!con) + { + ecpg_raise(lineno, ECPG_NO_CONN, ECPG_SQLSTATE_CONNECTION_DOES_NOT_EXIST, + connection_name ? connection_name : ecpg_gettext("NULL"));
Thanks for the feedback, Fujii. I agree—using ecpg_init() is a more consistent approach and aligns with how this is handled in other parts of the code.
I have updated the patch to use ecpg_init() for validation. Please find the revised version attached.
The patch works for MASTER and all the back branches.
