[sqlite] db->pVtabCtx and xCreate accessing a virtual table
The sqlite3 struct has a pVtabCtx pointer. It seems to me that it will be shared between multiple xCreate in action simultaniously and in that case cause disaster. This can happen even if there is no thread concurrency going on using the same database connection. My xCreate has to run some queries in order to build its declare statement. If a virtual table is queried inside xCreate causing a another xCreate to be called, the following sqlite3_declare_vtab will fail because pVtabCtx gets erased. Is this a design flaw of sqlite or intentionally designed this way for a good reason? The only workaround that I can think of is to fork() in xCreate having the child build the statement for the parent's sqlite3_declare_vtab(), pass that to the waiting parent and exit. But in my case the child would also have to pass a lot of other variable length information back to the parent, which will involve a lot of IPC mess to implement. -- Steinar ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] db->pVtabCtx and xCreate accessing a virtual table
On Thu, Apr 26, 2012 at 5:07 PM, Steinar Midtskogen wrote: > The sqlite3 struct has a pVtabCtx pointer. It seems to me that it > will be shared between multiple xCreate in action simultaniously and > in that case cause disaster. This can happen even if there is no > thread concurrency going on using the same database connection. > > My xCreate has to run some queries in order to build its declare > statement. If a virtual table is queried inside xCreate causing a > another xCreate to be called, the following sqlite3_declare_vtab will > fail because pVtabCtx gets erased. > Fixed here: http://www.sqlite.org/src/info/696a5a40bb > > Is this a design flaw of sqlite or intentionally designed this way for > a good reason? > > The only workaround that I can think of is to fork() in xCreate having > the child build the statement for the parent's sqlite3_declare_vtab(), > pass that to the waiting parent and exit. But in my case the child > would also have to pass a lot of other variable length information > back to the parent, which will involve a lot of IPC mess to implement. > > -- > Steinar > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] db->pVtabCtx and xCreate accessing a virtual table
Richard Hipp writes: > On Thu, Apr 26, 2012 at 5:07 PM, Steinar Midtskogen > wrote: > >> My xCreate has to run some queries in order to build its declare >> statement. If a virtual table is queried inside xCreate causing a >> another xCreate to be called, the following sqlite3_declare_vtab will >> fail because pVtabCtx gets erased. >> > > Fixed here: http://www.sqlite.org/src/info/696a5a40bb Thanks. I can confirm that it fixes everything for me. One other thing which perhaps is surprising, but it can be argued that it is a feature rather than a bug, is that a virtual table can be queried before its xCreate gets finished and its sqlite3_declare_vtab is called. So if someone says CREATE VIRTUAL TABLE x ... and its xCreate has a SELECT ... FROM x, it wont get "no such table". Rather it will call itself and eventually crash unless xCreate takes care to test for the recursion somehow. -- Steinar ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
