Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
| От | Andrew Dunstan |
|---|---|
| Тема | Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL |
| Дата | |
| Msg-id | db9c9fa1-4f7f-4b42-8d44-7b5bc3027bcf@dunslane.net обсуждение |
| Ответ на | Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: