> > 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/policyd-users
