> > Please, if you're going to read the source code, at least do a thorough > > job of it. Do NOT change the MySQL queries until you understand exactly > > what is happening and why. > > > > There is NO limit of 100 000, read the source code properly. > >To be more specific, follow from function to function: > >cleanup.c -> mysql.c -> db_deletequery(); > >db_deletequery() >.. > count=0; >.. >start: >.. > /* fire off query */ > if (w_mysql_query(fd, "db_deletequery") != 0) >.. > /* MySQL does not handle extremely large deletes very well */ > if((int)mysql_affected_rows(mysql) == 100000) > { > count=count+(int)mysql_affected_rows(mysql); > goto start; > ^^^^^^^^^^^ > | >Re-run the delete query if we hit up against the 100 000 limit >as this gives MySQL a small "breather" window. (Keep re-running >the delete query until there is less than 100 000 rows deleted) > >Running cleanup in DEBUG=3 mode shows you what is happening >in step-by-step detail.
Sorry Cami, I missed the loop. This was initially noticed by watching the mysql process monitor and seeing LIMIT 100000 at the end of the policyd cleanup queries. I missed entirely the loop which exists that resends the query if 100000 rows were affected. With that explanation it makes perfect sense. Thank you for pointing that out. I feel a little hammered by your reply, I was only trying to contribute and help. We're running 5.0.x version of mysql, I wonder if 5.0 or 5.1 has better delete code than previous versions which may eliminate the issue of large deletes. - Nate ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ policyd-users mailing list policyd-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/policyd-users