On 2/9/14, 10:58 PM, Branko Čibej wrote:
>> I just wonder when we started to rely on a particular query plan.
>
> It turns out to be more complex than that. I started bisecting to find the
> revision that broke trunk, and found that in r1542765, op-depth-test changed
> its failure mode from, e.g.,
>
> /Users/brane/src/svn/repos/trunk/subversion/libsvn_subr/sqlite.c:313: (apr_err=SVN_ERR_SQLITE_CONSTRAINT)
> svn_tests: E200035: sqlite[S19]: WC DB validity check 03 failed
>
> to the current, e.g.,
>
> svn_tests: E200006: expected {3, "A/B-move/C", "base-deleted", moved-to A/B-move/C-move}; found {3, "A/B-move/C", "base-deleted"}
> FAIL: op-depth-test 12: test_wc_move
>
> However, this does not happen with the same tests; in r1542764, op-depth-test
> #12 passes, but other tests fail with the constraint error. Given the above, my
> best guess is that these two errors are not related in any way, and that
> STMT_INSTALL_SCHEMA_STATISTICS is simply broken if the sqlite_stat3 or
> sqlite_stat4 tables are enabled and/or present.
This turned out to be a bug introduced into SQLite when the STAT4 option was
added.
https://www.sqlite.org/src/info/4c86b126f2
r1566960 tries our best to catch people using these options at configure time
and fail. I've tested this with trunk and 1.8.x and it works. Nominated for
backport.
I've also issued a pull request against the upstream homebrew project to stop
using this option:
https://github.com/Homebrew/homebrew/pull/26592
If we can get votes for the backport I'll roll 1.8.7 and we'll be back on our way.
Received on 2014-02-11 10:33:30 CET