[sqlite] Fwd: Re: [sx-users] Corruption storage

Hi, We got a report of a 'pragma integrity_check' failure on the user mailing list for our application [1]. There was no data loss involved (just the index was corrupted), but I thought you might want to take a look. The database was written to by our application (SX 2.0) which uses SQLite

[sqlite] Warnings for non-deterministic queries?

On 11/27/2015 08:30 PM, R Smith wrote: > > > On 2015/11/27 4:44 PM, Adam Devita wrote: >> I think the OP meant to write: >> "If the expression is an aggregate expression, it is evaluated across >> all rows in the group. Otherwise, it is evaluated against a single >> arbitrarily chosen row from

[sqlite] Warnings for non-deterministic queries?

Hi, I mistakenly used the wrong side of the ON caluse in a group by clause for a query and I was wondering why SQLite didn't return the same results always: - SELECT SUM(x) FROM (SELECT files.size + LENGTH(CAST(files.name AS BLOB)) + SUM(COALESCE(LENGTH(CAST(fmeta.key AS BLOB)) +

[sqlite] Fwd: Re: [sx-users] Corruption storage

On 11/25/2015 06:19 PM, Richard Hipp wrote: >> >> The I/O path is more complicated than I originally thought though: >> FreeBSD server (running our app with SQLite) with UFS+SU -> Linux (Xen host) >> -> FreeBSD (ISCSI + ZFS) > > I don't know what this means. Is there a network filesystem

[sqlite] Fwd: Re: [sx-users] Corruption storage

On 11/25/2015 05:37 PM, Richard Hipp wrote: > On 11/25/15, T?r?k Edwin wrote: >> Hi, >> >> A user of our application (CC-ed) reported a corruption in an SQLite DB on >> FreeBSD (see below). There was no mmap used in this case, just a WAL DB with >> PRAGMA

[sqlite] Fwd: Re: [sx-users] Corruption storage

Hi, A user of our application (CC-ed) reported a corruption in an SQLite DB on FreeBSD (see below). There was no mmap used in this case, just a WAL DB with PRAGMA SYNCHRONOUS=NORMAL. >From my reading of the SQLite docs this should not result in a corrupt DB, >worst case some COMMITs could be

[sqlite] SQLITE vs. OSX mmap == inevitable catalog corruption?

On 11/17/2015 12:11 AM, Deon Brewis wrote: > We found that using SQLITE memory mapped I/O (mmap_size > 0) in OSX isn't > usable in any way shape or form. It will inevitably lead to catalog > corruption if you hard-reboot OSX, even without the database or application > open. > I tried to turn

[sqlite] documentation: autoindex vs automatic index

Hi, The SQLite documentation does a good job explaining what an 'automatic index' is [1], so when someone looks at 'explain query plan' output and sees something like this they get worried: SEARCH TABLE fmeta USING INDEX sqlite_autoindex_fmeta_1 (file_id=?) The link above[1] uses #autoindex,

[sqlite] safety of WAL with SQLITE_THREADSAFE=0 on SMP system with multiple processes

Hi, When -DSQLITE_THREADSAFE=0 is used then unixShmBarrier becomes a noop because unixEnterMutex/unixLeaveMutex are empty functions. Digging through the SQLite source code I found this comment: /* Read the header. This might happen concurrently with a write to the ** same area of shared memory

[sqlite] Thanks SQLite

On 07/30/2015 01:32 AM, Richard Hipp wrote: > On 7/29/15, R.Smith wrote: >> >> I just wish to ... display my gratitude ... for ... CTE's. >> > > Glad you find them useful. > > I'm looking for real-world (open-source) use cases for CTEs. Please > send me links find any. We use CTE in Skylable

[sqlite] SQLite version 3.8.11 coming soon...

On 07/15/2015 08:34 PM, T?r?k Edwin wrote: > On 07/15/2015 08:17 PM, Richard Hipp wrote: >> On 7/15/15, T?r?k Edwin wrote: >>> This might be just the test runner and not sqlite itself, I'm not sure: >>> >>> Time: capi2.test 25 ms >>>

[sqlite] SQLite version 3.8.11 coming soon...

On 07/15/2015 08:17 PM, Richard Hipp wrote: > On 7/15/15, T?r?k Edwin wrote: >> This might be just the test runner and not sqlite itself, I'm not sure: >> >> Time: capi2.test 25 ms >> = >> ==2330==ERROR:

[sqlite] SQLite version 3.8.11 coming soon...

On 07/15/2015 06:59 PM, Richard Hipp wrote: > On 7/15/15, T?r?k Edwin wrote: >>> >>> 1) unknown-crash (might be due to some alignment requirements in asan): >> >> Build with clang 3.4 shows a heap-use-after-free instead of unknown-crash, >> and building a normal (just

[sqlite] SQLite version 3.8.11 coming soon...

On 07/15/2015 06:19 PM, Richard Hipp wrote: > On 7/15/15, T?r?k Edwin wrote: >> On 07/15/2015 12:05 AM, Richard Hipp wrote: >> >> I've run the address and undefined behaviour sanitizer (+ usual hardening >> and bug finding flags from Debian) from GCC 4.9.2 on Debian

[sqlite] SQLite version 3.8.11 coming soon...

On 07/15/2015 05:59 PM, T?r?k Edwin wrote: > On 07/15/2015 12:05 AM, Richard Hipp wrote: >> The plan is to release SQLite version 3.8.11 on or about the end of July. >> >> The current code is passing all tests that we have run against it. >> Some soak tests are still running. There are quite a

[sqlite] SQLite version 3.8.11 coming soon...

On 07/15/2015 12:05 AM, Richard Hipp wrote: > The plan is to release SQLite version 3.8.11 on or about the end of July. > > The current code is passing all tests that we have run against it. > Some soak tests are still running. There are quite a few > cross-platform tests (running on PPC, Sparc,

[sqlite] sqlite doesn't log reason for failing to open WAL file

Hi, When SQLite fails to create a file it tries reopening readonly and only if that fails too it logs the error. However by that time the original error (for file creation) is lost. Testcase: $ cat >testcase.sh

[sqlite] sqlite3 fails due to too long path (MAX_PATHNAME)

Hi, I was testing long pathnames and ran into this failure: $ sqlite3

[sqlite] SQLITE_PROTOCOL errors

On 06/06/2014 11:37 AM, Török Edwin wrote: > On 05/27/2014 01:49 PM, Török Edwin wrote: >> On 05/27/2014 01:40 PM, Richard Hipp wrote: >>> If you are getting PROTOCOL errors, then the thing to do is to describe the >>> circumstances under which the errors occur

Re: [sqlite] SQLite version 3.8.5 beta

On 05/27/2014 01:49 PM, Török Edwin wrote: > On 05/27/2014 01:40 PM, Richard Hipp wrote: >>> SQLite 3.8.4.3 still has the SQLITE_PROTOCOL bug with WAL databases [1], >>> and I don't see anything about that in the changes list. >>> Is it still a know bug in 3.8.5?

Re: [sqlite] SQLite version 3.8.5 beta

On 05/27/2014 01:40 PM, Richard Hipp wrote: > On Tue, May 27, 2014 at 4:18 AM, Török Edwin <edwin+sqli...@etorok.net>wrote: > >> On 05/27/2014 02:24 AM, Richard Hipp wrote: >>> Please download beta snapshots of SQLite 3.8.5 from >>> http://www.sqlite.org

Re: [sqlite] SQLite version 3.8.5 beta

On 05/27/2014 02:24 AM, Richard Hipp wrote: > Please download beta snapshots of SQLite 3.8.5 from > http://www.sqlite.org/download.html and test them in your applications. We > hope to release SQLite version 3.8.5 within the next few weeks. > > See

[sqlite] warning for partial indexes with "X AND Y"?

Hi, Would it be possible to show a message when someone creates a useless index such as index 'x' below? (at least if you have a logger defined via SQLITE_CONFIG_LOG) sqlite> create table foo(a int, b int); sqlite> create index x on foo(a,b) where a=0 and b=0; sqlite> explain query plan select *

[sqlite] Handling SQLITE_PROTOCOL with WAL databases

Hi, I encounter the same issue as described here: https://www.mail-archive.com/sqlite-users%40sqlite.org/msg57092.html usually once or twice a day, when running a performance test-suite for my application (using SQLite 3.8.1). What is the correct way to handle the SQLITE_PROTOCOL errors that

[sqlite] SQLite3 and EINTR

Hi, If I send signals to a process that is running an sqlite query on a DB in WAL mode I get an SQLITE_BUSY error. I did set a busy handler, and the timeout hasn't elapsed yet, so it appears that EINTR is treated as an error and not retried, although I haven't tracked down exactly where. I

[sqlite] SQLite3 temporary filename collision in worker processes

Hi, I am using SQLite 3.8.1 compiled from the amalgamation on Debian GNU/Linux "wheezy", amd64. I have set a logging callback with sqlite3_config(SQLITE_CONFIG_LOG, qlog, NULL), and I see the following error sometimes: Query "INSERT INTO topush (block, size, node, expires_at) VALUES (:b, :s,