Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
Date
Msg-id ahTckwyxLba5ofwq@paquier.xyz
Whole thread
In response to Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL  (Shruthi Gowda <gowdashru@gmail.com>)
Responses Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: NULL pointer dereference in syslogger with load_libraries() and -DEXEC_BACKEND at startup
Next
From: Xuneng Zhou
Date:
Subject: Re: Implement waiting for wal lsn replay: reloaded