I really found it this time.
While I was looking over the code changes, I noticed a section of code
dealing with case OP_VerifyCookie:
Inside that section is the following in 3.7.6
if( u.av.iMeta!=pOp->p2 || u.av.iGen!=pOp->p3 ){
sqlite3DbFree(db, p->zErrMsg);
p->zErrMsg = sqlite3DbStrDup(db, "database schema has changed");
/* If the schema-cookie from the database file matches the cookie
** stored with the in-memory representation of the schema, do
** not reload the schema from the database file.
**
** If virtual-tables are in use, this is not just an optimization.
** Often, v-tables store their data in other SQLite tables, which
** are queried from within xNext() and other v-table methods using
** prepared queries. If such a query is out-of-date, we do not want to
** discard the database schema, as the user code implementing the
** v-table would have to be ready for the sqlite3_vtab structure itself
** to be invalidated whenever sqlite3_step() is called from within
** a v-table method.
*/
if( db->aDb[pOp->p1].pSchema->schema_cookie!=u.av.iMeta ){
sqlite3ResetInternalSchema(db, pOp->p1);
}
On a hunch, I replaced this line:
if( u.av.iMeta!=pOp->p2 || u.av.iGen!=pOp->p3 ){
with the if statement from 3.7.5
if( u.av.iMeta!=pOp->p2 ){
When I do, the number of mallocs drops back to 14,000 - still a little
higher than in 3.7.5, but nowhere near 140,000.
Does that help?
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
