Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL

On Tue, May 26, 2026 at 5:04 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Mon, May 25, 2026 at 01:16:20PM +0530, Shruthi Gowda wrote:
> > Thanks Satya for looking into this. However, we don't need to add the
> > validation here because the caller ecpg_do_prologue*()* has already taken
> > care of it. Adding it again would be redundant. What do you think?
>
> Right, but I think that this points at a different issue: it is
> wasteful to call a second time ecpg_get_connection() to get a
> connection while ecpg_do_prologue() has already done a cache lookup
> for the connection.
>
> Wouldn't it be better to pass directly the connection obtained by the
> first call of ecpg_get_connection() as a function argument of
> ecpg_auto_prepare(), replacing the connection name? If we need the
> extra init() at the end, please show if this can go wrong in the shape
> of a regression test.
> --
> Michael
>
I agree. We can avoid the duplicate call to ecpg_get_connection() by
passing the connection object directly to ecpg_auto_prepare(). However, we
still need to pass the connection name as well, because underlying
functions inside ecpg_auto_prepare()—such as ECPGprepare() and
AddStmtToCache()— expect the connection name as an argument. Furthermore,
ECPGprepare() corresponds directly to the embedded SQL EXEC SQL PREPARE
statement, meaning we cannot entirely avoid calling ecpg_get_connection()
within that flow anyway.

Thanks & Regards,
Shruthi K C
EnterpriseDB: http://www.enterprisedb.com