[sqlite] Potential bug with compile-time option SQLITE_OMIT_AUTOVACUUM

Hi, Building amalgamation sqlite3.c with option SQLITE_OMIT_AUTOVACUUM=1 leads to malformed database on following case : Windows 7 x64, mingw64 5.4 : gcc -s -static -DSQLITE_OMIT_AUTOVACUUM=1 shell.c sqlite3.c -o sqlite3.exe using CLI (compiled with SQLITE_OMIT_AUTOVACUUM=1) : .open

Re: [sqlite] potential bug

On 04/17/2017 10:42 PM, Bernard Schurdevin wrote: Hi, I get weird results (false positive) to PRAGMA foreign_key_check on WITHOUT ROWID table depending on foreign key field position. Thanks for reporting this. Should be fixed here: http://www.sqlite.org/src/info/690870bd7b2e607b Dan.

[sqlite] potential bug

Hi, I get weird results (false positive) to PRAGMA foreign_key_check on WITHOUT ROWID table depending on foreign key field position. Kind regards. = -- tested with Window CLI, versions 3.8.5, 3.9.2, 3.14.1,

Re: [sqlite] Potential bug: Database on gvfs mount cannot be committed to

On 19 Sep 2016, at 2:52am, Keith Medcalf wrote: > That is to say there is no difference between a block device (such as a > physical hard disk) attached to the computer via a 1 foot SCSI cable and an > iSCSI LUN where the iSCSI block device is located on a different

Re: [sqlite] Potential bug: Database on gvfs mount cannot be committed to

No database server product of which I am aware will "work" properly when the database resides on a remote filesystem. There is a *vast* difference between a "remote file system" and a "local file system on a remote block device". There is no difference between a "remote block device" known as

Re: [sqlite] Potential bug: Database on gvfs mount cannot be committed to

"snapshotable" or not, DBs are accessed from the local file system, not from a network where another OS has control of the file system. On Sun, Sep 18, 2016 at 10:16 AM, Florian Weimer wrote: > * R. Smith: > > > Enterprise DBs have servers on the same machine as the Files

Re: [sqlite] Potential bug: Database on gvfs mount cannot be committed to

* R. Smith: > Enterprise DBs have servers on the same machine as the Files they > access, they do not actually use the network file-system to access the > DB data-files over the network from multiple clients, or even servers > (unless the DBs are partitioned so and ONLY accessed by the single >

[sqlite] Potential bug: Database on gvfs mount cannot be committed to

On 2015-09-12 06:30 PM, Florian Weimer wrote: >> On 09/06/2015 11:13 AM, Florian Weimer wrote: >>> Surely that's not true, and NFS and SMB are fine as long as there >>> is no concurrent access? >> And no program crashes, no network glitches, no optimisation in the >> protocols to deal with

[sqlite] Potential bug: Database on gvfs mount cannot be committed to

* Roger Binns: > On 09/06/2015 11:13 AM, Florian Weimer wrote: >> Surely that's not true, and NFS and SMB are fine as long as there >> is no concurrent access? > > And no program crashes, no network glitches, no optimisation in the > protocols to deal with latency, nothing else futzing with the

[sqlite] Potential bug: Database on gvfs mount cannot be committed to

On 09/06/2015 09:23 PM, Roger Binns wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 09/06/2015 06:16 AM, Markus Weiland wrote: >> I've discovered a potential bug in handling of SQLite database >> files on gvfs mounted network shares. > SQLite doesn't support being stored on the

[sqlite] Potential bug: Database on gvfs mount cannot be committed to

On 6 Sep 2015, at 9:16pm, Roger Binns wrote: > no programs futzing with them (backup agents, virus scanners etc) Reminds me of my most annoying SQLite problem. They were running a virus scanner which delayed temp file deletion and SQLite could not manage its journal files properly. Took me

[sqlite] Potential bug: Database on gvfs mount cannot be committed to

* Roger Binns: > On 09/06/2015 06:16 AM, Markus Weiland wrote: >> I've discovered a potential bug in handling of SQLite database >> files on gvfs mounted network shares. > > SQLite doesn't support being stored on the network for several > reasons, including that network file protocols don't

[sqlite] Potential bug: Database on gvfs mount cannot be committed to

I see. Since this was working under Ubuntu 14.04, I assume this is a regression with gvfs. I'll check over there. On 2015-09-06 06:00 PM, sqlite-users-request at mailinglists.sqlite.org wrote: > On 09/06/2015 06:16 AM, Markus Weiland wrote: >> >I've discovered a potential bug in handling of

[sqlite] Potential bug: Database on gvfs mount cannot be committed to

Hi, I've discovered a potential bug in handling of SQLite database files on gvfs mounted network shares. Steps to reproduce: 1. Under vanilla Ubuntu 15.04 with latest official patches and SQLite version 2.8.17, mount a Windows / SMB network share via Nautilus file manager. The share can be

[sqlite] Potential bug: Database on gvfs mount cannot be committed to

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/06/2015 11:13 AM, Florian Weimer wrote: > Surely that's not true, and NFS and SMB are fine as long as there > is no concurrent access? And no program crashes, no network glitches, no optimisation in the protocols to deal with latency, nothing

[sqlite] Potential bug: Database on gvfs mount cannot be committed to

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/06/2015 10:20 AM, Markus Weiland wrote: > I see. Since this was working under Ubuntu 14.04, I assume this is > a regression with gvfs. I'll check over there. Nope. SQLite can not maintain data integrity when used with *any* network filesystem.

[sqlite] Potential bug: Database on gvfs mount cannot be committed to

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/06/2015 06:16 AM, Markus Weiland wrote: > I've discovered a potential bug in handling of SQLite database > files on gvfs mounted network shares. SQLite doesn't support being stored on the network for several reasons, including that network file

Re: [sqlite] SQLite - potential bug with multiple leftjoin/groupby/count

Harry Beezhold wrote: > Sqlite - What a cool product! Do you really think buggy products are cool? ;-) > The following is a description of an apparent bug in > the calculation of a row count of a left joined table. > The leftjoin/count technique seems to work for each join/count, separately.

Re: [sqlite] SQLite - potential bug with multiple leftjoin/groupby/count

On Tue, Sep 3, 2013 at 10:41 AM, Harry Beezhold wrote: > > > The attached database (view.db) has 3 tables > The sqlite-users@sqlite.org mailing list strips off attachments. Can you send a link instead? -- D. Richard Hipp d...@sqlite.org

[sqlite] SQLite - potential bug with multiple leftjoin/groupby/count

Hi, Sqlite - What a cool product! The following is a description of an apparent bug in the calculation of a row count of a left joined table. In the intended application I plan to use this type of query to feed and filter the list on the "choose a person" popup in a genealogy

Re: [sqlite] Potential bug in crash-recovery code: unlink() and friends are not synchronous

atabase. > > -Original Message- > From: sqlite-users-boun...@sqlite.org [mailto: > sqlite-users-boun...@sqlite.org] On Behalf Of thanumalayan mad > Sent: Wednesday, May 22, 2013 8:31 AM > To: Richard Hipp > Cc: General Discussion of SQLite Database > Subject: Re: [sqlite] Pote

Re: [sqlite] Potential bug in crash-recovery code: unlink() and friends are not synchronous

Database Subject: Re: [sqlite] Potential bug in crash-recovery code: unlink() and friends are not synchronous I do not observe any loss in durability in WAL mode: it works totally fine. As for the documentation, http://www.sqlite.org/transactional.html and http://www.sqlite.org/features.html claim

Re: [sqlite] Potential bug in crash-recovery code: unlink() and friends are not synchronous

I do not observe any loss in durability in WAL mode: it works totally fine. As for the documentation, http://www.sqlite.org/transactional.html and http://www.sqlite.org/features.html claim that SQLite is durable during power failures; and DELETE is the default journal_mode. Also, other pages,

Re: [sqlite] Potential bug in crash-recovery code: unlink() and friends are not synchronous

Dear fellow SQLite afficionados,   Thanumalayan Sankaranarayana Pillai wrote:   "I expect it wouldn't be a problem with WAL" Thé SQLite (not wanting, but cobsidering him at leat  kind of) Force D. Richard H.  [who does not know Him don't read this message, you won;t

Re: [sqlite] Potential bug in crash-recovery code: unlink() and friends are not synchronous

No, I have reported everything. The only thing I missed might be that it's not "5 seconds" always, but rather the configurable commit interval of the filesystem, which is by default 5 seconds in most desktop Linux distros. I only read through the source code of test6.c, and misunderstood that

Re: [sqlite] Potential bug in crash-recovery code: unlink() and friends are not synchronous

On Wed, May 22, 2013 at 8:31 AM, thanumalayan mad wrote: > > Also, not to spam, but it would be great if you could answer these > questions for my research (you might send me a reply directly without going > through the mailing list): [a] Was it always understood that unlink()

Re: [sqlite] Potential bug in crash-recovery code: unlink() and friends are not synchronous

On Sat, May 18, 2013 at 4:41 AM, thanumalayan mad wrote: > > Expected result: You always find that the transaction had been executed. > Observed result: You sometimes find that the transaction did not execute. > The core team has discussed this. In order to avoid a

Re: [sqlite] Potential bug in crash-recovery code: unlink() and friends are not synchronous

Thank you for your replies! I now fully understand (and appreciate) that the "ACI" part of transactions is the most important. Also, I didn't notice any of ACI being broken: SQLite guarantees those conditions really well. However, just to be clear, my "potential bug" affects out-of-the-box Fedora

Re: [sqlite] Potential bug in crash-recovery code: unlink() and friends are not synchronous

On Tue, May 21, 2013 at 12:04 PM, Thanumalayan Sankaranarayana Pillai < madth...@cs.wisc.edu> wrote: > Hi all, > > Did anyone look into this? I might be setting some config option wrong, > so it would be great if you sent me a "you did something wrong" reply if > you feel that I might have the

Re: [sqlite] Potential bug in crash-recovery code: unlink() and friends are not synchronous

On 21 May 2013, at 5:04pm, Thanumalayan Sankaranarayana Pillai wrote: > Did anyone look into this? I might be setting some config option wrong, > so it would be great if you sent me a "you did something wrong" reply if > you feel that I might have the wrong config (or

Re: [sqlite] Potential bug in crash-recovery code: unlink() and friends are not synchronous

Hi all, Did anyone look into this? I might be setting some config option wrong, so it would be great if you sent me a "you did something wrong" reply if you feel that I might have the wrong config (or might be doing something totally idiotic). I tested with a few other Linux machines and a few

[sqlite] Potential bug in crash-recovery code: unlink() and friends are not synchronous

Hi All, I was testing out SQLite with a framework I developed. I believe, while running on Linux, transactions might not be durable when a power crash happens immediately after a commit. I observed this using "SQLite version 3.7.16.2 2013-04-12 11:52:43", and kernel "3.8.4-102.fc17.x86_64". Steps

Re: [sqlite] Potential bug: "insert into X select * from Y" ignores the "ON CONFLICT REPLACE" conflict-clause

Simon L wrote 2011-10-25 06:20: To reproduce this problem, enter the following 5 SQL statements at the SQLite command line. create table X(id INTEGER primary key ON CONFLICT REPLACE); create table Y(id INTEGER primary key ON CONFLICT REPLACE); insert into X values (1); insert into Y select *

[sqlite] Potential bug: "insert into X select * from Y" ignores the "ON CONFLICT REPLACE" conflict-clause

To reproduce this problem, enter the following 5 SQL statements at the SQLite command line. create table X(id INTEGER primary key ON CONFLICT REPLACE); create table Y(id INTEGER primary key ON CONFLICT REPLACE); insert into X values (1); insert into Y select * from X; insert into Y select * from

[sqlite] Potential Bug, Select appears to hang

There are more fields in each table, but for the sake of brevity, I ommited them from the snippets below. With smaller data sets, the second query works just fine as well. SELECT COUNT(*) FROM link; 960219 SELECT COUNT(*) FROM node; 812193 Pvid's are INTEGERS. On linux, the following query