public inbox for [email protected]  
help / color / mirror / Atom feed
From: Andrew Dunstan <[email protected]>
To: Tom Lane <[email protected]>
Cc: Alexander Lakhin <[email protected]>
Cc: Nishant Sharma <[email protected]>
Cc: Shruthi Gowda <[email protected]>
Cc: Mahendra Singh Thalor <[email protected]>
Cc: Fujii Masao <[email protected]>
Cc: PostgreSQL Development <[email protected]>
Subject: Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
Date: Wed, 6 May 2026 11:50:04 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CAASxf_P1F75Ck+0qyb10auT+BORupOM4yigXBnm7aWRNx1LYcA@mail.gmail.com>
	<CADrsxdbb2fn1LACQShrQT0bNqSCQ3hSzEojb2tODhD0PmewDiA@mail.gmail.com>
	<CAASxf_OdsJRi17EZ_ZMyQgOwUzn357YyMqJ2Z2qiExPaLRW_Lg@mail.gmail.com>
	<CADrsxdbPw1ZYcuqH1-DTNhAvRN=tRTTY+_dFy8wU2g4DQb67Bg@mail.gmail.com>
	<CAASxf_PtXCsmu5oCvZH4BmLdojG+0XJUH8foHFZv+2vmsSbNwA@mail.gmail.com>
	<CADrsxdZMOc6qkoVcyp67+Ez8cesey3iDVaVm617oSpiDdf=5xQ@mail.gmail.com>
	<CAASxf_OkeXLZy6r7f05-LjwxgHEXJymQgifU27CAvWEYfY7uVA@mail.gmail.com>
	<CADrsxdZhGHj96ZYy9GR6U9yLtTshfOU-3DFd0aoz70C5S3Np5g@mail.gmail.com>
	<CAASxf_O+CN9Pw+XSHCbfHE2DwS1BObAwFZnnQyT+7062ozYGQw@mail.gmail.com>
	<CADrsxdb_7nCwjfoFJ3p3QvOyQtZUkDVm0aqX73bWd+27tOTO7w@mail.gmail.com>
	<CAD5tBcL7rMgeykb2ZRF3t00SaWzOhtVME-fDqvspH88d+rosFw@mail.gmail.com>
	<75460b3c-2! [email protected]>
	<[email protected]>
	<[email protected]>
	<53e7527c-eb! [email protected]>
	<[email protected]>


On 2026-05-06 We 10:58 AM, Tom Lane wrote:
> Andrew Dunstan <[email protected]> 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.


I agree.


>
> 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.
>
> 			


Right.


Given the lack of field complaints, maybe we should wait until after 
next week's releases?


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com






reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox