[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: wc_db performance

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Tue, 15 Mar 2011 12:52:42 +0000

Stefan Sperling <stsp_at_elego.de> writes:

> On Tue, Mar 15, 2011 at 10:26:15AM +0000, Philip Martin wrote:
>> Branko ─îibej <brane_at_e-reka.si> writes:
>> > The restriction that you may not invoke a callback from within a sqlite
>> > transaction remains. That's what the temporary results tables are for --
>> > they live outside transactions on the main wc-db.
>> I don't understand the temporary table approach. Taking the
>> temp__node_props_cache table as an example: it gets populated by a
>> transaction and lives beyond that transaction. The table then gets
>> queried by a second transaction and the callbacks are made while that
>> second transaction is in progress. So callbacks are still being invoked
>> from within a transaction.
> It works around the infinite loop problem that happens when the
> callback inserts rows that end up being picked up by the proplist query.
> Which is silly for this callback to do, but then again we somehow agreed
> that the callbacks are free to do virtually anything. (I still think
> putting newly documented restrictions on them now is fine and would make
> our life easier... *shrug*).

I'm still confused. I thought the infinite loop problem affected the
old multiple transaction code. If we simply ran a single transaction
and made callbacks then that problem would not exist. We would have the
same limitations that apply to the temporary table approach: the
callback cannot write to the database because a transaction is in

>> As far as I can see using a temporary table has made the overall "read
>> properties" operation into one that modifies the database, to create the
>> temporary table. I guess that by the time the callbacks are made the
>> database write-lock has been dropped, but there would have been no
>> write-lock if the temporary table were not used.
> I think the temporary table gets put into a separate database file
> (or memory, depending on the temp_store pragma or whatsitcalled).
> If so, a read lock on the primary db should suffice, shouldn't it?

Yes, by the time we invoke the callbacks we have a read-lock. If we
simply ran a single transaction and made callbacks within the
transaction then it would have the same effect. I don't see what the
temporary table achieves.

Received on 2011-03-15 13:53:17 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.