]> git.ipfire.org Git - thirdparty/asterisk.git/commit
res_config_pgsql.c: Fix deadlock loading realtime configuration. 40/1440/1
authorRichard Mudgett <rmudgett@digium.com>
Wed, 14 Oct 2015 19:15:53 +0000 (14:15 -0500)
committerRichard Mudgett <rmudgett@digium.com>
Wed, 14 Oct 2015 19:18:45 +0000 (14:18 -0500)
commitdc6ec661b3f109e196a60f1285d6554f25efa12f
treec07e19baf21b04bad755d1977ebc6afff80743b2
parentf8707ae9a57b47a742c051e6714416f46b156118
res_config_pgsql.c: Fix deadlock loading realtime configuration.

On v13, loading several thousand PJSIP endpoints on Asterisk start causes
a deadlock most of the time.

Thanks to mdu113 for discovering that there was a call to pgsql_exec() not
protected by the pgsql_lock reentrancy lock.

{quote}
I believe a code path exists that attempts to use pgsql connection without
locking pgsql_lock.  I believe what happens during that deadlock that I
see is two concurrent threads are both attempting to send query to pgsql,
one of the thread is using a code path without locking pgsql_lock.  If
they managed to send queries at the same time, it seems postgres ignores
one of the queries and replies only to the one of them.  If it happens so
that the thread holding the lock didn't receive the reply it will wait for
it (and hold the lock) forever (or at least for very long time), thus
completely blocking all access to db.
{quote}

* Added missing reentrancy locking around pgsql_exec() in find_table().

* Moved unlock of pgsql_lock in unload_module() to avoid locking inversion
between the psql_tables list lock and the pgsql_lock.

ASTERISK-25455 #close
Reported by:  mdu113
Patches:
      res_config_pgsql.c-connlock2.diff (license #5543) patch uploaded by mdu113

Change-Id: Id9e7cdf8a3b65ff19964b0cf942ace567938c4e2
res/res_config_pgsql.c