Horton

Thread

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

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

    Shruthi Gowda <gowdashru@gmail.com> — 2025-12-08T15:38:56Z

    Hi,

The ECPG application crashes with a segmentation fault when calling
specific deallocation or prepared statement functions without an
established database connection. This is caused by a missing NULL check on
the connection handle before attempting to access it.

The issue is reproducible on the MASTER branch and affects older versions
up to v13.

The issue can be reproduced by modifying existing test cases, such as
src/interfaces/ecpg/test/sql/execute.pgc or
src/interfaces/ecpg/test/sql/desc.pgc. The general method is to skip the EXEC
SQL CONNECT statement (or intentionally force the connection to fail).

To specifically isolate the crash in ECPGdeallocate_all() and prevent the
program from hitting the ECPGprepared_statement() crash first, modify the
desc.pgc test file by moving the EXEC SQL DEALLOCATE ALL statement to an
earlier point

*Seg fault in ECPGprepared_statement():*
[434574]: ECPGdebug: set to 1
[434574]: ECPGconnect: opening database ecpg1_regression on <DEFAULT> port
<DEFAULT>
[434574]: ECPGconnect: connection to server on socket "/tmp/.s.PGSQL.5444"
failed: FATAL:  database "ecpg1_regression" does not exist
[434574]: ecpg_finish: connection main closed
[434574]: raising sqlcode -402 on line 24: could not connect to database
"ecpg1_regression" on line 24
SQL error: could not connect to database "ecpg1_regression" on line 24
[434574]: raising sqlcode -220 on line 25: connection "NULL" does not exist
on line 25
SQL error: connection "NULL" does not exist on line 25
[434574]: raising sqlcode -220 on line 26: connection "NULL" does not exist
on line 26
SQL error: connection "NULL" does not exist on line 26
[434574]: raising sqlcode -220 on line 29: connection "NULL" does not exist
on line 29
SQL error: connection "NULL" does not exist on line 29
[434574]: raising sqlcode -220 on line 32: connection "NULL" does not exist
on line 32
SQL error: connection "NULL" does not exist on line 32
[434574]: raising sqlcode -220 on line 35: connection "NULL" does not exist
on line 35
SQL error: connection "NULL" does not exist on line 35
Inserted 0 tuples via execute immediate
[434574]: raising sqlcode -220 on line 40: connection "NULL" does not exist
on line 40
SQL error: connection "NULL" does not exist on line 40
[434574]: raising sqlcode -220 on line 41: connection "NULL" does not exist
on line 41
SQL error: connection "NULL" does not exist on line 41
Inserted 0 tuples via prepared execute
[434574]: raising sqlcode -220 on line 45: connection "NULL" does not exist
on line 45
SQL error: connection "NULL" does not exist on line 45
[434574]: raising sqlcode -220 on line 49: connection "NULL" does not exist
on line 49
SQL error: connection "NULL" does not exist on line 49

Program received signal SIGSEGV, Segmentation fault.
0x0000fffff7f92654 in ecpg_find_prepared_statement (name=0xaaaaaaaa1aa8
"f", con=0x0, prev_=0x0) at prepare.c:277
277             for (this = con->prep_stmts, prev = NULL;
(gdb) bt
#0  0x0000fffff7f92654 in ecpg_find_prepared_statement (name=0xaaaaaaaa1aa8
"f", con=0x0, prev_=0x0) at prepare.c:277
#1  0x0000fffff7f92aa8 in ecpg_prepared (name=0xaaaaaaaa1aa8 "f", con=0x0)
at prepare.c:393
#2  0x0000fffff7f92afc in ECPGprepared_statement (connection_name=0x0,
name=0xaaaaaaaa1aa8 "f", lineno=53)
    at prepare.c:404

#3  0x0000aaaaaaaa0f74 in main () at
/home/shrkc/work/postgres/inst/bin/execute.pgc:52



*Seg fault in ECPGdeallocate_all() :*


Program received signal SIGSEGV, Segmentation fault.
0x0000fffff7f92a2c in ecpg_deallocate_all_conn (lineno=25,
c=ECPG_COMPAT_PGSQL, con=0x0) at prepare.c:372
372             while (con->prep_stmts)
(gdb) bt
#0  0x0000fffff7f92a2c in ecpg_deallocate_all_conn (lineno=25,
c=ECPG_COMPAT_PGSQL, con=0x0) at prepare.c:372
#1  0x0000fffff7f92a78 in ECPGdeallocate_all (lineno=25, compat=0,
connection_name=0x0) at prepare.c:384
#2  0x0000aaaaaaaa0e60 in main () at
/home/shrkc/work/postgres/inst/bin/desc.pgc:25


Please find the proposed patch attached below for your review.


Thanks & Regards,

Shruthi K C

EnterpriseDB: http://www.enterprisedb.com

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

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-12-08T16:09:55Z

    Shruthi Gowda <gowdashru@gmail.com> writes:
> The ECPG application crashes with a segmentation fault when calling
> specific deallocation or prepared statement functions without an
> established database connection. This is caused by a missing NULL check on
> the connection handle before attempting to access it.

Hmm ... poking around, I see several other places that aren't checking
the result of ecpg_get_connection.  Shouldn't we tighten them all?

			regards, tom lane

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

    Andrew Dunstan <andrew@dunslane.net> — 2026-05-01T19:20:40Z

    On Wed, Apr 22, 2026 at 12:27 AM Nishant Sharma <
nishant.sharma@enterprisedb.com> wrote:

> Thanks Shruthi!
>
> v5 code, v4_test and v4_test_15 patches look good to me.
>
> I checked ECPG regression on master, REL_18, REL_17, REL_16, REL_15,
> REL_14 using both make and meson.
>
> I have finished my review work on the patches. Thank you!
>
>
>
>
Thanks, everybody, pushed (as combined patches)

cheers

andrew

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

    Alexander Lakhin <exclusion@gmail.com> — 2026-05-05T20:00:00Z

    Hello hackers,

01.05.2026 22:20, Andrew Dunstan wrote:
>
> On Wed, Apr 22, 2026 at 12:27 AM Nishant Sharma <nishant.sharma@enterprisedb.com> wrote:
>
>     Thanks Shruthi!
>
>     v5 code, v4_test and v4_test_15 patches look good to me.
>
>     I checked ECPG regression on master, REL_18, REL_17, REL_16, REL_15, REL_14 using both make and meson.
>
>     I have finished my review work on the patches. Thank you!
>
>
> Thanks, everybody, pushed (as combined patches)

Despite this improvement committed, dikkop keeps producing segfaults
during ecpg test, e.g., [1], [2]:
ok 62        - thread/thread_implicit                    224 ms
not ok 63    - thread/prep                               116 ms
# (test process was terminated by signal 11: Segmentation fault)
ok 64        - thread/alloc                              406 ms

There is no other useful information in the log, so it's not clear what's
wrong with that animal (no other gives us such failures), but I could
produce something similar (on FreeBSD and Linux) with:
echo "max_connections = 10" >/tmp/temp.config; TEMP_CONFIG=/tmp/temp.config gmake -s check -C src/interfaces/ecpg/test

not ok 64    - thread/prep                                29 ms
# (test process was terminated by signal 11: Segmentation fault)

not ok 65    - thread/alloc                               27 ms
# (test process was terminated by signal 11: Segmentation fault)

gdb src/interfaces/ecpg/test/thread/prep src/interfaces/ecpg/test/core.3371028
Core was generated by `.../src/interfaces/ecpg/test/thread/prep'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007478ad3a8301 in deallocate_one (lineno=lineno@entry=45, c=c@entry=ECPG_COMPAT_PGSQL, 
con=con@entry=0x747888000ca0, prev=0x0, this=0x74788800ad40)
     at prepare.c:313
313 this->stmt->connection->connection,
[Current thread is 1 (Thread 0x7478a1c006c0 (LWP 3371041))]
(gdb) bt
#0  0x00007478ad3a8301 in deallocate_one (lineno=lineno@entry=45, c=c@entry=ECPG_COMPAT_PGSQL, 
con=con@entry=0x747888000ca0, prev=0x0, this=0x74788800ad40)
     at prepare.c:313
#1  0x00007478ad3a8a32 in ECPGprepare (lineno=lineno@entry=45, connection_name=connection_name@entry=0x0, 
questionmarks=questionmarks@entry=false,
     name=name@entry=0x5d934a41b024 "i", variable=variable@entry=0x7478a1bffdb0 "INSERT INTO T VALUES ( ? )") at 
prepare.c:264
#2  0x00005d934a41a536 in fn (arg=<optimized out>) at .../src/interfaces/ecpg/test/thread/prep.pgc:45
#3  0x00007478ad09caa4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447
#4  0x00007478ad129c3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

(gdb) p this->stmt
$1 = (struct statement *) 0x242028205345554c
(gdb) p this->stmt->connection
Cannot access memory at address 0x2420282053455564

gdb src/interfaces/ecpg/test/thread/alloc src/interfaces/ecpg/test/core.3371068
Core was generated by `.../src/interfaces/ecpg/test/thread/alloc'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  pqRowProcessor (conn=conn@entry=0x7962f4000d60, errmsgp=errmsgp@entry=0x7963151ffbd0) at fe-exec.c:1226
1226            int                     nfields = res->numAttributes;
[Current thread is 1 (Thread 0x7963152006c0 (LWP 3371075))]
(gdb) bt
#0  pqRowProcessor (conn=conn@entry=0x7962f4000d60, errmsgp=errmsgp@entry=0x7963151ffbd0) at fe-exec.c:1226
#1  0x00007963188e9d44 in getAnotherTuple (conn=conn@entry=0x7962f4000d60, msgLength=14) at fe-protocol3.c:849
#2  0x00007963188eb42b in pqParseInput3 (conn=conn@entry=0x7962f4000d60) at fe-protocol3.c:388
#3  0x00007963188e0e69 in parseInput (conn=conn@entry=0x7962f4000d60) at fe-exec.c:2039
#4  0x00007963188e3d74 in PQgetResult (conn=conn@entry=0x7962f4000d60) at fe-exec.c:2125
#5  0x00007963188e3fec in PQexecStart (conn=conn@entry=0x7962f4000d60) at fe-exec.c:2386
#6  0x00007963188e40a7 in PQexec (conn=0x7962f4000d60, query=0x7962e8000ca0 "select relname from pg_class where relname 
= 'pg_class'") at fe-exec.c:2281
#7  0x0000796318948620 in ecpg_execute (stmt=0x7962e8009e60) at execute.c:1619
#8  0x00007963189494fc in ecpg_do (lineno=<optimized out>, compat=<optimized out>, force_indicator=<optimized out>, 
connection_name=<optimized out>,
     questionmarks=questionmarks@entry=false, st=<optimized out>, query=0x5a5947b97028 "select relname from pg_class 
where relname = 'pg_class'",
     args=0x7963151ffcf0) at execute.c:2273
#9  0x00007963189495b7 in ECPGdo (lineno=lineno@entry=45, compat=compat@entry=0, force_indicator=force_indicator@entry=1,
     connection_name=connection_name@entry=0x0, questionmarks=questionmarks@entry=false, st=st@entry=0,
     query=0x5a5947b97028 "select relname from pg_class where relname = 'pg_class'") at execute.c:2298
#10 0x00005a5947b963b8 in fn (arg=<optimized out>) at .../src/interfaces/ecpg/test/thread/alloc.pgc:45
#11 0x000079631869caa4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447
#12 0x0000796318729c3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
(gdb) p conn
$1 = (PGconn *) 0x7962f4000d60
(gdb) p conn->result
$2 = (PGresult *) 0x0

Could you please look if such crashes can be prevented too?

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dikkop&dt=2026-05-04%2010%3A00%3A10
[2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dikkop&dt=2026-05-03%2021%3A25%3A17

Best regards,
Alexander

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

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-05-05T20:32:41Z

    Alexander Lakhin <exclusion@gmail.com> writes:
> There is no other useful information in the log, so it's not clear what's
> wrong with that animal (no other gives us such failures), but I could
> produce something similar (on FreeBSD and Linux) with:
> echo "max_connections = 10" >/tmp/temp.config; TEMP_CONFIG=/tmp/temp.config gmake -s check -C src/interfaces/ecpg/test

Yes, I can also reproduce problems with the ecpg tests at
max_connections = 10.  For me, thread/prep segfaults but thread/alloc
just seems to hang indefinitely.  (thread/prep sometimes does too.)
These issues are not new; v18 does the same.  The reporting is a
bit different but I think that's from pg_regress changes not ecpg.

Looking at the postmaster log, I see

2026-05-05 16:11:06.509 EDT [682116] FATAL:  sorry, too many clients already

which is unsurprising in this situation, but apparently these tests
don't handle a connection failure well at all.

There's no such message in dikkop's log, so that may be an unrelated problem.

BTW, reducing max_connections to 5 causes several other tests to fail,
but in unsurprising ways, like

# +SQL error: could not connect to database "ecpg1_regression" on line 107
# +SQL error: could not connect to database "ecpg1_regression" on line 107
# +SQL error: could not connect to database "ecpg1_regression" on line 107
# +SQL error: could not connect to database "ecpg1_regression" on line 107


			regards, tom lane

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

    Andrew Dunstan <andrew@dunslane.net> — 2026-05-05T21:36:02Z

    On 2026-05-05 Tu 4:32 PM, Tom Lane wrote:
> Alexander Lakhin <exclusion@gmail.com> writes:
>> There is no other useful information in the log, so it's not clear what's
>> wrong with that animal (no other gives us such failures), but I could
>> produce something similar (on FreeBSD and Linux) with:
>> echo "max_connections = 10" >/tmp/temp.config; TEMP_CONFIG=/tmp/temp.config gmake -s check -C src/interfaces/ecpg/test
> Yes, I can also reproduce problems with the ecpg tests at
> max_connections = 10.  For me, thread/prep segfaults but thread/alloc
> just seems to hang indefinitely.  (thread/prep sometimes does too.)
> These issues are not new; v18 does the same.  The reporting is a
> bit different but I think that's from pg_regress changes not ecpg.
>
> Looking at the postmaster log, I see
>
> 2026-05-05 16:11:06.509 EDT [682116] FATAL:  sorry, too many clients already
>
> which is unsurprising in this situation, but apparently these tests
> don't handle a connection failure well at all.
>
> There's no such message in dikkop's log, so that may be an unrelated problem.
>
> BTW, reducing max_connections to 5 causes several other tests to fail,
> but in unsurprising ways, like
>
> # +SQL error: could not connect to database "ecpg1_regression" on line 107
> # +SQL error: could not connect to database "ecpg1_regression" on line 107
> # +SQL error: could not connect to database "ecpg1_regression" on line 107
> # +SQL error: could not connect to database "ecpg1_regression" on line 107
>
>
> 			


Ugh. I will do some digging.


cheers


andrew


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

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

    Andrew Dunstan <andrew@dunslane.net> — 2026-05-06T11:55:10Z

    On 2026-05-05 Tu 5:36 PM, Andrew Dunstan wrote:
>
> On 2026-05-05 Tu 4:32 PM, Tom Lane wrote:
>> Alexander Lakhin <exclusion@gmail.com> writes:
>>> There is no other useful information in the log, so it's not clear 
>>> what's
>>> wrong with that animal (no other gives us such failures), but I could
>>> produce something similar (on FreeBSD and Linux) with:
>>> echo "max_connections = 10" >/tmp/temp.config; 
>>> TEMP_CONFIG=/tmp/temp.config gmake -s check -C src/interfaces/ecpg/test
>> Yes, I can also reproduce problems with the ecpg tests at
>> max_connections = 10.  For me, thread/prep segfaults but thread/alloc
>> just seems to hang indefinitely.  (thread/prep sometimes does too.)
>> These issues are not new; v18 does the same.  The reporting is a
>> bit different but I think that's from pg_regress changes not ecpg.
>>
>> Looking at the postmaster log, I see
>>
>> 2026-05-05 16:11:06.509 EDT [682116] FATAL:  sorry, too many clients 
>> already
>>
>> which is unsurprising in this situation, but apparently these tests
>> don't handle a connection failure well at all.
>>
>> There's no such message in dikkop's log, so that may be an unrelated 
>> problem.
>>
>> BTW, reducing max_connections to 5 causes several other tests to fail,
>> but in unsurprising ways, like
>>
>> # +SQL error: could not connect to database "ecpg1_regression" on 
>> line 107
>> # +SQL error: could not connect to database "ecpg1_regression" on 
>> line 107
>> # +SQL error: could not connect to database "ecpg1_regression" on 
>> line 107
>> # +SQL error: could not connect to database "ecpg1_regression" on 
>> line 107
>>
>>
>>
>
>
> Ugh. I will do some digging.
>
>
>

OK, first this is orthogonal to the issue fixed earlier in this thread.

It's a 22 yer old bug where a connection failure results in a thread 
falling back to a sibling's connection. The fix is to keep track of 
which thread opened which connection and only fall back to the global 
actual_connection if it was started by our thread.

There was an unresolved report of these symptoms in 2006[1]. 
Essentially, the user was holding the lock the docs told him to hold, 
and ecpglib still corrupted state because the corruption window was 
inside ecpglib, not inside the libpq calls he was trying to serialize. 
It's not an easy problem to diagnose, however, so there could well have 
been more cases.

Attached is a patch with the fix, courtesy of claude. It's a slight 
behaviour change:

After the patch, programs in this category fail loudly with ECPG_NO_CONN:

- Pattern that breaks: main thread calls EXEC SQL CONNECT, spawns 
workers, workers issue EXEC SQL ... with no connection name and no 
per-thread SET CONNECTION, relying on their own mutex to serialize the 
libpq calls.
- Migration: one of two existing supported patterns. Either name the 
connection explicitly per statement (EXEC SQL AT con1 SELECT ...) or set 
the per-thread default once at thread start (EXEC SQL SET CONNECTION 
con1;). The
   latter still works under the patch because it explicitly populates 
the per-thread slot, and the patch only owner-checks the global 
fallback, not the per-thread slot.

So I guess the question is whether or not we backpatch it (or some other 
fix)?


cheers


andrew



[1] 
https://www.postgresql.org/message-id/52940eef0611100514p14c85e34l528da656662decc9@mail.gmail.com


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

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

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-05-06T14:58:27Z

    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

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

    Andrew Dunstan <andrew@dunslane.net> — 2026-05-06T15:50:04Z

    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

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

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-05-06T16:02:08Z

    Andrew Dunstan <andrew@dunslane.net> writes:
> Given the lack of field complaints, maybe we should wait until after 
> next week's releases?

Yeah, given that this bug has gone almost undetected for decades,
I don't think there's a rush.  Let's sit on it another week.

			regards, tom lane

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

    SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com> — 2026-05-23T18:59:44Z

    Hi

On Fri, May 1, 2026 at 12:21 PM Andrew Dunstan <andrew@dunslane.net> wrote:

>
>
> On Wed, Apr 22, 2026 at 12:27 AM Nishant Sharma <
> nishant.sharma@enterprisedb.com> wrote:
>
>> Thanks Shruthi!
>>
>> v5 code, v4_test and v4_test_15 patches look good to me.
>>
>> I checked ECPG regression on master, REL_18, REL_17, REL_16, REL_15,
>> REL_14 using both make and meson.
>>
>> I have finished my review work on the patches. Thank you!
>>
>>
>>
>>
> Thanks, everybody, pushed (as combined patches)
>

Looks like this committed a case, attached a patch to fix this.

Thanks,
Satya

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

    Shruthi Gowda <gowdashru@gmail.com> — 2026-05-25T07:46:20Z

    On Sun, May 24, 2026 at 12:29 AM SATYANARAYANA NARLAPURAM <
satyanarlapuram@gmail.com> wrote:

> Hi
>
> On Fri, May 1, 2026 at 12:21 PM Andrew Dunstan <andrew@dunslane.net>
> wrote:
>
>>
>>
>> On Wed, Apr 22, 2026 at 12:27 AM Nishant Sharma <
>> nishant.sharma@enterprisedb.com> wrote:
>>
>>> Thanks Shruthi!
>>>
>>> v5 code, v4_test and v4_test_15 patches look good to me.
>>>
>>> I checked ECPG regression on master, REL_18, REL_17, REL_16, REL_15,
>>> REL_14 using both make and meson.
>>>
>>> I have finished my review work on the patches. Thank you!
>>>
>>>
>>>
>>>
>> Thanks, everybody, pushed (as combined patches)
>>
>
> Looks like this committed a case, attached a patch to fix this.
>
> Thanks,
> Satya
>
>
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?

Thanks & Regards,

Shruthi K C

EnterpriseDB: http://www.enterprisedb.com

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

    Michael Paquier <michael@paquier.xyz> — 2026-05-25T23:34:43Z

    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

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

    Shruthi Gowda <gowdashru@gmail.com> — 2026-05-26T11:40:02Z

    On Tue, May 26, 2026 at 5:04 AM Michael Paquier <michael@paquier.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