Re: BUG #17186: In connect.c, the lock connections_mutex is not correctly released(Line 463) at the return(Line 522)
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: ryancaicse@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2021-09-11T05:38:47Z
Lists: pgsql-bugs
Attachments
- ecpg-connect-threads.patch (text/plain) patch
On Fri, Sep 10, 2021 at 04:07:26PM +0900, Michael Paquier wrote: > ecpg_alloc() is just a wrapper to calloc(), so errors are very > unlikely going to happen in this code path. It does not change the > fact that it is wrong. Nice catch, will fix. After looking at the issue in depth, I have noticed that just unlocking the pthread mutex is incorrect because we would still free a connection object while is is *tracked* by the list of all the connections. In normal cases, we should just call ecpg_finish() to correctly clean up the new connection from the list. But I don't think that we need to do any of that at this stage, and instead we had better move the allocation for the connection parameters before doing the list manipulation, saving from any cleanup action needed. That also means moving up a bit the calculations we do for connect_params when looking at all the parameters. And that means losing a log but as the connection failed on OOM, it is not like we need to care anyway. If a client is under memory pressure, that could really mess up applications and the list of connections, so this had better be backpatched. -- Michael
Commits
-
Fix error handling with threads on OOM in ECPG connection logic
- 3768c468df58 9.6.24 landed
- 83a3737a63a5 10.19 landed
- b6a10ff4abe9 11.14 landed
- b34dcf87f685 12.9 landed
- b589d212fdd7 13.5 landed
- cc057fb315e2 14.0 landed
- fa703b317e9d 15.0 landed
-
Detect POLLHUP/POLLRDHUP while running queries.
- c30f54ad732c 14.0 cited