summaryrefslogtreecommitdiff
path: root/contrib
diff options
context:
space:
mode:
authorRichard Mudgett <rmudgett@digium.com>2015-10-14 14:15:53 -0500
committerRichard Mudgett <rmudgett@digium.com>2015-10-14 14:18:45 -0500
commitdc6ec661b3f109e196a60f1285d6554f25efa12f (patch)
treec07e19baf21b04bad755d1977ebc6afff80743b2 /contrib
parentf8707ae9a57b47a742c051e6714416f46b156118 (diff)
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
Diffstat (limited to 'contrib')
0 files changed, 0 insertions, 0 deletions