← Back to team overview

agesys-dev team mailing list archive

[Bug 1168150] [NEW] Parametrized query hits max_prepared_stmt_count

 

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


Follow ups

References