Regresson on trunk with SQLite 3.8 [was: Re: 1.8.6 up for testing/signing]

[Branko Čibej <br...@wandisco.com>]

> 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.

-- Brane


-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com

Re: Regresson on trunk with SQLite 3.8 [was: Re: 1.8.6 up for testing/signing]

[Ben Reser <be...@reser.org>]

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.