src/sqlite3.c:80663
--------------
if( pOp->p1==1 ){
/* Invalidate all prepared statements whenever the TEMP database
** schema is changed. Ticket #1644 */
sqlite3ExpirePreparedStatements(db);
p->expired = 0;
}
--------------
SQLITE_PRIVATE void sqlite3ExpirePreparedStatements(sqlite3 *db){
Vdbe *p;
for(p = db->pVdbe; p; p=p->pNext){
p->expired = 1;
}
}
------------
[https://www.sqlite.org/src/info/4cd4efaf5ef40a07]
"Expire all prepared statements whenever there is a change to the
schema of the TEMP database. Ticket #1644. (CVS 3036)"
checkin.c::status_report() prepares a "SELECT ...,
checkin_mtime()...." statement.
checkin_mtime() in descendants.c::mtime_of_manifest_file() may DROP
and CREATE a TEMP table.
When it does (on a first try) it causes the whole prepared statement
chain to expire.
Looks like checkin_mtime() SQL function was not intended to be called
in nested statements.
I wonder if this issue could be replicated in a simpler statement to
isolate the chain expiration.
On Sun, Nov 6, 2016 at 2:21 PM, Andy Goth <andrew.m.g...@gmail.com> wrote:
> The issue seems to be resolved for now. Phone typing is hard, so just have a
> look at check-in 5258a43d78. I'll quickly summarize: the schema was getting
> changed right in the middle of running a prepared statement.
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
