Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Alexander Lakhin <exclusion@gmail.com>, Nishant Sharma <nishant.sharma@enterprisedb.com>, Shruthi Gowda <gowdashru@gmail.com>, Mahendra Singh Thalor <mahi6run@gmail.com>, Fujii Masao <masao.fujii@gmail.com>, PostgreSQL Development <pgsql-hackers@postgresql.org>
Date: 2026-05-06T14:58:27Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add missing connection validation in ECPG

Andrew Dunstan <andrew@dunslane.net> writes:
> Attached is a patch with the fix, courtesy of claude. It's a slight 
> behaviour change:

Yeah.  So we could either do something like this, or say that the
test case is buggy and needs to provide its own mutexes, per the
existing comment

-         * if no connection in TSD for this thread, get the global default
-         * connection and hope the user knows what they're doing (i.e. using
-         * their own mutex to protect that connection from concurrent accesses

On the whole I think I favor the behavior change.  We might get some
complaints, but it just seems a lot safer to redefine it like this.

Either way, it seems like some documentation adjustments are called
for.

As far as the patch itself goes, I'd be inclined to pull the
preparatory step

         ecpg_pthreads_init();    /* ensure actual_connection_key is valid */

into the new ecpg_default_connection() subroutine, especially since
its proposed comment doesn't mention that prerequisite.

			regards, tom lane