From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | ryancaicse(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17186: In connect.c, the lock connections_mutex is not correctly released(Line 463) at the return(Line 522) |
Date: | 2021-09-11 05:38:47 |
Message-ID: | YTxA58Jtg5y6y+se@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
Attachment | Content-Type | Size |
---|---|---|
ecpg-connect-threads.patch | text/plain | 2.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Lakhin | 2021-09-11 09:00:00 | Re: BUG #17182: Race condition on concurrent DROP and CREATE of dependent object |
Previous Message | Tom Lane | 2021-09-10 19:27:50 | Re: BUG #17158: Distinct ROW fails with Postgres 14 |