Yep. Its in dbmysql.c all right.
I hateses globals :-/
Storing the last_row_nr in a global variable is a flawed approach. I
assume a static like last_row_nr is an optimization that wants to
outsmart the mysql api. Such optimizations however, should, have and
will occur in the mysql libs. So, is there a solid, benchmarked reason
for avoiding use of mysql_data_seek and mysql_fetch_row.
My trivial patch:
diff -r1.84 dbmysql.c
156a157
> /*
163a165,167
> */
> mysql_data_seek(res, row);
> last_row = mysql_fetch_row(res);
fixes the problem I've been having with _ic_list.
Looking into this some further I noticed db_query tries to avoid
mysql_store_result, where the mysql docs clearly state such calls are ok:
------ info: mysql_store_result -----
You must call `mysql_store_result()' or `mysql_use_result()' for every
query that successfully retrieves data (`SELECT', `SHOW', `DESCRIBE',
`EXPLAIN').
You don't have to call `mysql_store_result()' or `mysql_use_result()'
for other queries, but it will not do any harm or cause any notable
performance if you call `mysql_store_result()' in all cases. You can
detect if the query didn't have a result set by checking if
`mysql_store_result()' returns 0 (more about this later one).
------------------------------------
Reading this db_query just doesn't look right to me. What do you think
Ilja ?
Btw, the testsuite now runs ok with the patch mentioned :-) So can we
clean up dbmysql.c a little and move on ?
I read about you fixing the sigpipe error. Have you committed any
changes to that effect?
Ilja Booij wrote:
Paul J Stevens wrote:
I did a backtrace and concluded the same. I also added some debugging
statements in db_get_result_u64 and got something interesting return
values from db_get_result:
Mar 31 13:10:25 shiko dbmail/imap4d[17930]:
db.c,db_list_mailboxes_by_regex: comparing mailbox
[#Users/testuser1/testbox] to regular expressionMar 31 13:10:25 shiko
dbmail/imap4d[17930]: db.c,db_get_result_u64: result [^S]
hmm.. interesting indeed. I take it that the ^S is the value of the tmp
string in db_get_result_u64()?
If so, the result from db_get_result() is off. You're using MySQL,
right? Maybe you should add some debug statements in mysql/dbmysql.c, to
see if anything goes wrong there.
I've looked through db_get_result() again, but can't seem to find
anything wrong.. Glad we narrowed down the search though.
Ilja
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
