The problem: One long-running unixODBC query blocks all others from the same application.
Odbc Thread level should be set:
/* * use just one mutex for all the lists, this avoids any issues * with deadlocks, the performance issue should be minimal, if it * turns out to be a problem, we can readdress this * * We also have a mutex to protect the connection pooling code * * If compiled with thread support the DM allows four different * thread strategies * * Level 0 - Only the DM internal structures are protected * the driver is assumed to take care of it's self * * Level 1 - The driver is protected down to the statement level * each statement will be protected, and the same for the connect * level for connect functions, note that descriptors are considered * equal to statements when it comes to thread protection. * * Level 2 - The driver is protected at the connection level. only * one thread can be in a particular driver at one time * * Level 3 - The driver is protected at the env level, only one thing * at a time. * * By default the driver open connections with a lock level of 3, * this can be changed by adding the line * * Threading = N * * to the driver entry in odbcinst.ini, where N is the locking level * (0-3) * */
Recommended UnixODBC settings for postgres
Description = General ODBC for PostgreSQL Driver = /usr/lib64/libodbcpsql.so Setup = /usr/lib64/libodbcpsqlS.so FileUsage = 1 # Since 1.6 if the driver manager was built with thread support you may add another entry to each driver entry. # This entry alters the default thread serialization level. Threading = 2
Thanks for sharing.
Check it out. https://theopinionatedindian.com/how-to-find-social-activity-spots-to-interact-with-people-in-your-city/
Please sign in to leave a comment.