Thread

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