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

From Andrew Dunstan
Subject Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
Date
Msg-id cb83c14f-7247-409b-ba5c-04c7402adc6b@dunslane.net
Whole thread
In response to Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
List pgsql-hackers
On 2026-05-06 We 10:58 AM, Tom Lane wrote:
> 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.


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




pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Changing the state of data checksums in a running cluster
Next
From: Andres Freund
Date:
Subject: Re: Make printtup a bit faster