res_config_pgsql.c: Fix deadlock loading realtime configuration.
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:56 +0000 (14:18 -0500)
commitd799bcf3614bbcad8b26ebc9ea515bcb0765c800
tree642cb6e85472ab7c3c732b1bbed315ec90992c71
parent13229037d19dad06759fbf14521b8055e52d6039
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