Public bug reported: Hi,
I have a script that executes the same query over and over for a large number of times. The script would eventually raise ProgrammingError, with the following message (1461, "Can't create more than max_prepared_stmt_count statements (current value: 16382)") The attached code should reproduce the bug (it will connect to mysql based on the paramenters in ~/my.cnf). If you monitor the server's status (mysqladmin extended-status) you will notice that Prepared_stmt_count grows until it hits max_prepared_stmt_count. Also, you might notice that the memory usage of the script grows, slowly but steadily. The way I am getting around this is to embed the loop block within a try/except. When the exception is catched, I close the cursor and recreate a new one. It works great, and in fact Prepared_stmt_count goes back to 0, but I feel that it's a bit hackish. I looked up a bit on various fora and it seems that this might be due to a memory leak: http://forums.mysql.com/read.php?167,563765,563765#msg-563765 ** Affects: oursql Importance: Undecided Status: New ** Attachment added: "Reproducible example" https://bugs.launchpad.net/bugs/1168150/+attachment/3641248/+files/prepstmt.py -- You received this bug notification because you are a member of Agesys Team, which is subscribed to oursql. https://bugs.launchpad.net/bugs/1168150 Title: Parametrized query hits max_prepared_stmt_count Status in oursql: New Bug description: Hi, I have a script that executes the same query over and over for a large number of times. The script would eventually raise ProgrammingError, with the following message (1461, "Can't create more than max_prepared_stmt_count statements (current value: 16382)") The attached code should reproduce the bug (it will connect to mysql based on the paramenters in ~/my.cnf). If you monitor the server's status (mysqladmin extended-status) you will notice that Prepared_stmt_count grows until it hits max_prepared_stmt_count. Also, you might notice that the memory usage of the script grows, slowly but steadily. The way I am getting around this is to embed the loop block within a try/except. When the exception is catched, I close the cursor and recreate a new one. It works great, and in fact Prepared_stmt_count goes back to 0, but I feel that it's a bit hackish. I looked up a bit on various fora and it seems that this might be due to a memory leak: http://forums.mysql.com/read.php?167,563765,563765#msg-563765 To manage notifications about this bug go to: https://bugs.launchpad.net/oursql/+bug/1168150/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~agesys-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~agesys-dev More help : https://help.launchpad.net/ListHelp
