Re: BUG #17186: In connect.c, the lock connections_mutex is not correctly released(Line 463) at the return(Line 522) - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: BUG #17186: In connect.c, the lock connections_mutex is not correctly released(Line 463) at the return(Line 522)
Date
Msg-id YTxA58Jtg5y6y+se@paquier.xyz
Whole thread Raw
In response to 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>)
Responses 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>)
List 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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17158: Distinct ROW fails with Postgres 14
Next
From: Alexander Lakhin
Date:
Subject: Re: BUG #17182: Race condition on concurrent DROP and CREATE of dependent object