Re: [sqlite] Regarding the whole C89/C90 language compliance debacle ...
On 11/23/19 6:35 PM, Simon Slavin wrote: > On 23 Nov 2019, at 11:06pm, Richard Hipp wrote: > >> given the choice between >> >> (1) Code that works and does something useful >> (2) Code that is standards compliant >> >> I'll always go with (1). > Another problem is that different compilers, or the same compiler with > different options, warn about different things. And that making changes to > make one compiler happy can make another compiler unhappy. Until you end up > with > > complicated line here;/* actually does a = b but > must keep four compilers happy */ I consider it an error in specifications if there is a requirement for no warnings without specifying what compiler/options that requirement needs to be meet on. It can be shown to be impossible to get totally warning free code on arbitrary compilers. As to the original question, if the program uses the type long long, then it can't be C89/C90 compatible, as the type didn't exist then. It might be that the program given some option could make a variation that doesn't use long long for very old systems. As to the conversion between function pointers and data pointers, this ability is not specified in the C Standard, and on some machines it actually can't be done. POSIX compatibility requires that it works in at least some limited situation as an extension. (Originally, there was some confusion over if it required a diagnostic in fully conforming mode or not, of course enabling POSIX would suppress that message). Sometimes code is just easier to write (or performs better) if you use extensions provided by an implementation. Doing so limits what compilers can be used, but some GCC extensions are just so commonly available on a variety of platforms that the limitation is minor. -- Richard Damon ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Regarding the whole C89/C90 language compliance debacle ...
1 - I was taught C by kre back in 1982 (or was it 1983?), on a VAX called "munnari," for those who remember their history :-> I remember you however I started on BSD implementaions in 83 or 84 with the first real big workstations I had being the Apollo DN1000 and DN3000 boxen. Those things ran something called aegis which was essentially BSD. These were followed rapidly by the first big deskside Sun boxens on the old hypersparc or ross type chips in VME bus enclosures. Anyone recall the sweeping cpu led lights on the back of the cpu boards? Those were the early hardware implementations of the cylon ( BattleStar Gallactica and not the cool show either ) red eyes. Which was worth the price just to see them all going bonkers. Anyways .. yeah ... C and Fortran ( lots ) and Pascal but we don't talk about that. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Regarding the whole C89/C90 language compliance debacle ...
On 24/11/2019 10:35, Simon Slavin wrote: On 23 Nov 2019, at 11:06pm, Richard Hipp wrote: given the choice between (1) Code that works and does something useful (2) Code that is standards compliant I'll always go with (1). Another problem is that different compilers, or the same compiler with different options, warn about different things. And that making changes to make one compiler happy can make another compiler unhappy. Until you end up with complicated line here; /* actually does a = b but must keep four compilers happy */ Things like this remind me of Donald Knuth's line: "Beware of bugs in the above code; I have only proved it correct, not tried it." And over the decades[1] of writing (portable) C code I have sprinkled many such comments on how, "doing this makes it work on such-and-such a system" in many, many files. :-) Cheers, GaryB-) 1 - I was taught C by kre back in 1982 (or was it 1983?), on a VAX called "munnari," for those who remember their history :-> ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] sqldiff sameples
has anyone successfully used this tool to do a reconciliation between two tables, i am looking to do simple rec between two tables on same db or if need be on sep db with same table name with a key, it seems to not work very well or often gives me an error saying that table does not exist in both db even though when I do .tables I can clearly see and query the tables any samples of such would be greatly appreciated thanks O ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Regarding the whole C89/C90 language compliance debacle ...
On 11/23/19 11:35 PM, Simon Slavin wrote: On 23 Nov 2019, at 11:06pm, Richard Hipp wrote: given the choice between (1) Code that works and does something useful (2) Code that is standards compliant I'll always go with (1). Another problem is that different compilers, or the same compiler with different options, warn about different things. And that making changes to make one compiler happy can make another compiler unhappy. Until you end up with complicated line here; /* actually does a = b but must keep four compilers happy */ Thanks !! I needed that. I have been pouring over this for two weeks and the real issue is test suite. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Regarding the whole C89/C90 language compliance debacle ...
On 23 Nov 2019, at 11:06pm, Richard Hipp wrote: > given the choice between > > (1) Code that works and does something useful > (2) Code that is standards compliant > > I'll always go with (1). Another problem is that different compilers, or the same compiler with different options, warn about different things. And that making changes to make one compiler happy can make another compiler unhappy. Until you end up with complicated line here; /* actually does a = b but must keep four compilers happy */ ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] What is the C language standard to which sqlite conforms ?
On 11/23/19 4:46 PM, Dan Kennedy wrote: Some follow up and thank you all for looking at this. Using this mornings trunk/current/head I do see the tests running well with these little exceptions : boe13$ pwd /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.006 ... build clean as usual :-) tests run nicely now until ... Can you run: ./testfixture test/journal3.test and post the output? It would be my pleasure to get some light tossed on this ... so here is a very clean compile ( no -std in CFLAGS at all on gcc 9.2.0 ) and the tests look like so : . . . Time: zipfile.test 442 ms Time: zipfile2.test 45 ms SQLite 2019-11-21 20:24:04 ac080432b480062507452d3cdbe6c0f759e6f95b65d9862e0462017405ab2b8e 8 errors out of 250191 tests on boe13.genunix.com Linux 64-bit little-endian !Failures on these tests: journal3-1.2.1.1 journal3-1.2.1.4 journal3-1.2.2.1 journal3-1.2.2.4 journal3-1.2.3.1 journal3-1.2.3.4 journal3-1.2.4.1 journal3-1.2.4.4 All memory allocations freed - no leaks Maximum memory usage: 9267192 bytes Current memory usage: 0 bytes Number of malloc() : -1 calls gmake: *** [Makefile:1252: tcltest] Error 1 real 420.72 user 383.25 sys 23.47 boe13$ boe13$ ./testfixture test/journal3.test journal3-1.1... Ok journal3-1.2.1.1... ! journal3-1.2.1.1 expected: [0o644] ! journal3-1.2.1.1 got: [00644] journal3-1.2.1.2... Ok journal3-1.2.1.3... Ok journal3-1.2.1.4... ! journal3-1.2.1.4 expected: [0o644] ! journal3-1.2.1.4 got: [00644] journal3-1.2.1.5... Ok journal3-1.2.2.1... ! journal3-1.2.2.1 expected: [0o666] ! journal3-1.2.2.1 got: [00666] journal3-1.2.2.2... Ok journal3-1.2.2.3... Ok journal3-1.2.2.4... ! journal3-1.2.2.4 expected: [0o666] ! journal3-1.2.2.4 got: [00666] journal3-1.2.2.5... Ok journal3-1.2.3.1... ! journal3-1.2.3.1 expected: [0o600] ! journal3-1.2.3.1 got: [00600] journal3-1.2.3.2... Ok journal3-1.2.3.3... Ok journal3-1.2.3.4... ! journal3-1.2.3.4 expected: [0o600] ! journal3-1.2.3.4 got: [00600] journal3-1.2.3.5... Ok journal3-1.2.4.1... ! journal3-1.2.4.1 expected: [0o755] ! journal3-1.2.4.1 got: [00755] journal3-1.2.4.2... Ok journal3-1.2.4.3... Ok journal3-1.2.4.4... ! journal3-1.2.4.4 expected: [0o755] ! journal3-1.2.4.4 got: [00755] journal3-1.2.4.5... Ok SQLite 2019-11-21 20:24:04 ac080432b480062507452d3cdbe6c0f759e6f95b65d9862e0462017405ab2b8e 8 errors out of 22 tests on boe13.genunix.com Linux 64-bit little-endian !Failures on these tests: journal3-1.2.1.1 journal3-1.2.1.4 journal3-1.2.2.1 journal3-1.2.2.4 journal3-1.2.3.1 journal3-1.2.3.4 journal3-1.2.4.1 journal3-1.2.4.4 All memory allocations freed - no leaks Memory used: now 0 max 260520 max-size 12 Allocation count: now 0 max167 Page-cache used: now 0 max 0 max-size 1032 Page-cache overflow: now 0 max 2064 Maximum memory usage: 260520 bytes Current memory usage: 0 bytes Number of malloc() : -1 calls boe13$ Let me know if there is anything else I can try here. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Regarding the whole C89/C90 language compliance debacle ...
On 11/23/19 11:06 PM, Richard Hipp wrote: conforming to strict standards instead of what compilers actually do My problem here is that the compilers and their ability to comply with those wonderful cross platform standards is always a moving picture. Regardless it may be of some value to put a note somewhere on the sqlite webpages that says "just use GCC and don't specify -std" or something more helpful. Having said all that the use-after-free bug is real and we may yet have other problems in the test harness. I am still working through that and doing testing on a multitude of architectures ( risc / cisc / big endian / little endian and 32 and 64 bit ) which tends to reveal issues. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Regarding the whole C89/C90 language compliance debacle ...
On 11/23/19, Peter da Silva wrote: > Strictly compliant code strictly doesn't need to do anything at all, > conforming to strict standards instead of what compilers actually do is an > interesting intellectual exercise but is not necessarily useful. Right. So given the choice between (1) Code that works and does something useful (2) Code that is standards compliant I'll always go with (1). Now, if we can add in (2) as well, without compromising (1), then so much the better. But the primary focus is always on (1). -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Regarding the whole C89/C90 language compliance debacle ...
Op za 23 nov. 2019 om 23:27 schreef Dennis Clarke: > /usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/src/tclsqlite.c: > "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/src/tclsqlite.c", > line 2624: warning: argument #3 is incompatible with prototype: > prototype: pointer to long : "/usr/local/include/tclDecls.h", > line 2866 Line 2611 of tclsqlite.c reads: sqlite3_int64 mxSize = 0; this should have been Tcl_WideInt mxSize = 0; Tcl_WideInt is guaranteed to be at least a 64-bit type, but it might be "long" or "long long" dependant on Tcl version or platform. So, the warning is harmless, understandable, and easy to fix. Regards, Jan Nijtmans ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Regarding the whole C89/C90 language compliance debacle ...
Strictly compliant code strictly doesn't need to do anything at all,
conforming to strict standards instead of what compilers actually do is an
interesting intellectual exercise but is not necessarily useful.
On Sat, Nov 23, 2019, 16:27 Dennis Clarke wrote:
>
> I may be the only person that does this sort of testing for my own
> reasons and perhaps for sanity checking also. I tend to think that if
> something is written to be compliant with C89/C90 then I should be able
> to run the most strict compliance compiler flags in creation and be
> perfectly happy.
>
> However that is not the case here wwith gcc 9.2.0 on RHEL 7.4 :
>
> ../sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009.compile.log
> /opt/bw/gcc9/bin/gcc -std=iso9899:1990 -pedantic -Wpedantic
> -pedantic-errors -O0 -m64 -g -march=k8 -mtune=k8
> -Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -o
> mksourceid
>
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c:23:25:
>
> error: ISO C90 does not support 'long long' [-Wlong-long]
> 23 | typedef unsigned long long int u64;
>| ^~~~
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c:
>
> In function 'KeccakF1600Step':
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c:74:5:
>
> error: use of C99 long long integer constant [-Wlong-long]
> 74 | 0x0001ULL, 0x8082ULL,
>| ^
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c:74:29:
>
> error: use of C99 long long integer constant [-Wlong-long]
> 74 | 0x0001ULL, 0x8082ULL,
>| ^
>
> etc etc
>
> If we look :
>
> boe13$ head -80 tool/mksourceid.c | tail
>u64 C0, C1, C2, C3, C4;
>u64 D0, D1, D2, D3, D4;
>static const u64 RC[] = {
> 0x0001ULL, 0x8082ULL,
> 0x8000808aULL, 0x800080008000ULL,
> 0x808bULL, 0x8001ULL,
> 0x800080008081ULL, 0x80008009ULL,
> 0x008aULL, 0x0088ULL,
> 0x80008009ULL, 0x800aULL,
> 0x8000808bULL, 0x808bULL,
> boe13$
>
> Here I am using some very strict flags and note the -fno-builtin :
>
> boe13$ echo $CFLAGS
> -std=iso9899:1990 -pedantic -Wpedantic -pedantic-errors -O0 -m64
> -g -march=k8 -mtune=k8 -Wl,-rpath=/opt/bw/lib,--enable-new-dtags
> -fno-builtin -malign-double
> boe13$
>
> So that clearly isn't going to work here.
>
> So let's try -std=iso9899:1999 and see a different type of failure :
>
> /opt/bw/gcc9/bin/gcc -std=iso9899:1999 -O0 -m64 -g -pedantic
> -pedantic-errors -Wpedantic -march=k8 -mtune=k8
> -Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -o
> mksourceid
>
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c
> tclsh8.7
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksqlite3h.tcl
>
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009
> >sqlite3.h
> /opt/bw/gcc9/bin/gcc -std=iso9899:1999 -O0 -m64 -g -pedantic
> -pedantic-errors -Wpedantic -march=k8 -mtune=k8
> -Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -o
> mkkeywordhash
>
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mkkeywordhash.c
> ./mkkeywordhash >keywordhash.h
> /opt/bw/gcc9/bin/gcc -std=iso9899:1999 -O0 -m64 -g -pedantic
> -pedantic-errors -Wpedantic -march=k8 -mtune=k8
> -Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -o
> lemon
>
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c:
>
> In function 'main':
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c:1639:21:
>
> error: ISO C forbids conversion of function pointer to object pointer
> type [-Wpedantic]
> 1639 | {OPT_FSTR, "d", (char*)_d_option, "Output directory.
> Default '.'"},
>| ^
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c:1640:21:
>
> error: ISO C forbids conversion of function pointer to object pointer
> type [-Wpedantic]
> 1640 | {OPT_FSTR, "D", (char*)handle_D_option, "Define an %ifdef
> macro."},
>| ^
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c:1654:21:
>
> error: ISO C forbids conversion of function pointer to object pointer
> type [-Wpedantic]
> 1654 | {OPT_FSTR, "T", (char*)handle_T_option, "Specify a template
> file."},
>| ^
>
>
[sqlite] Regarding the whole C89/C90 language compliance debacle ...
I may be the only person that does this sort of testing for my own
reasons and perhaps for sanity checking also. I tend to think that if
something is written to be compliant with C89/C90 then I should be able
to run the most strict compliance compiler flags in creation and be
perfectly happy.
However that is not the case here wwith gcc 9.2.0 on RHEL 7.4 :
../sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009.compile.log
/opt/bw/gcc9/bin/gcc -std=iso9899:1990 -pedantic -Wpedantic
-pedantic-errors -O0 -m64 -g -march=k8 -mtune=k8
-Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -o
mksourceid
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c:23:25:
error: ISO C90 does not support 'long long' [-Wlong-long]
23 | typedef unsigned long long int u64;
| ^~~~
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c:
In function 'KeccakF1600Step':
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c:74:5:
error: use of C99 long long integer constant [-Wlong-long]
74 | 0x0001ULL, 0x8082ULL,
| ^
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c:74:29:
error: use of C99 long long integer constant [-Wlong-long]
74 | 0x0001ULL, 0x8082ULL,
| ^
etc etc
If we look :
boe13$ head -80 tool/mksourceid.c | tail
u64 C0, C1, C2, C3, C4;
u64 D0, D1, D2, D3, D4;
static const u64 RC[] = {
0x0001ULL, 0x8082ULL,
0x8000808aULL, 0x800080008000ULL,
0x808bULL, 0x8001ULL,
0x800080008081ULL, 0x80008009ULL,
0x008aULL, 0x0088ULL,
0x80008009ULL, 0x800aULL,
0x8000808bULL, 0x808bULL,
boe13$
Here I am using some very strict flags and note the -fno-builtin :
boe13$ echo $CFLAGS
-std=iso9899:1990 -pedantic -Wpedantic -pedantic-errors -O0 -m64
-g -march=k8 -mtune=k8 -Wl,-rpath=/opt/bw/lib,--enable-new-dtags
-fno-builtin -malign-double
boe13$
So that clearly isn't going to work here.
So let's try -std=iso9899:1999 and see a different type of failure :
/opt/bw/gcc9/bin/gcc -std=iso9899:1999 -O0 -m64 -g -pedantic
-pedantic-errors -Wpedantic -march=k8 -mtune=k8
-Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -o
mksourceid
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c
tclsh8.7
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksqlite3h.tcl
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009
>sqlite3.h
/opt/bw/gcc9/bin/gcc -std=iso9899:1999 -O0 -m64 -g -pedantic
-pedantic-errors -Wpedantic -march=k8 -mtune=k8
-Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -o
mkkeywordhash
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mkkeywordhash.c
./mkkeywordhash >keywordhash.h
/opt/bw/gcc9/bin/gcc -std=iso9899:1999 -O0 -m64 -g -pedantic
-pedantic-errors -Wpedantic -march=k8 -mtune=k8
-Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -o
lemon
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c:
In function 'main':
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c:1639:21:
error: ISO C forbids conversion of function pointer to object pointer
type [-Wpedantic]
1639 | {OPT_FSTR, "d", (char*)_d_option, "Output directory.
Default '.'"},
| ^
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c:1640:21:
error: ISO C forbids conversion of function pointer to object pointer
type [-Wpedantic]
1640 | {OPT_FSTR, "D", (char*)handle_D_option, "Define an %ifdef
macro."},
| ^
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c:1654:21:
error: ISO C forbids conversion of function pointer to object pointer
type [-Wpedantic]
1654 | {OPT_FSTR, "T", (char*)handle_T_option, "Specify a template
file."},
| ^
OKay so at this point I move over to an entirely separate system and
architecture wherein I have very strict POSIX compliance at all levels
and use the Oracle Studio 12.6 compiler tools. Specifically the c99
compiler there with -Xc strict compliance and a very few other flags.
This is a very well maintained sparc M-class Oracle/Fujitsu server on
maintenance contract and it runs very very stable and well :
beta$ pwd
Re: [sqlite] Concurrency Question
That's very helpful, thank you very much, Daniel. Also to Jens. I've re-read the SQLite documentation for shared cache now. I guess I had enabled it in the past to increase the performance (many threads in my application). Apparently, this had the opposite effect :-/ After disabling the shared cache mode, the locks no longer happen. As I had initially anticipated, the update and the read now run happily in parallel. Thanks again. On a weekend, even! ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Concurrency Question
> On Nov 23, 2019, at 7:17 AM, Dan Kennedy wrote: > > This should only happen if you are using shared-cache mode. Don't use > shared-cache mode. Shared-cache mode also breaks Isolation between connections — during a transaction, other connections will see the writer’s intermediate state. (IIRC. It’s been a few years.) In my experience, it’s only useful if all connections are read-only, or if you’re willing to use your own mutexes to keep writers from screwing up readers (in which case you might as well just share a single connection, right?) —Jens ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] What is the C language standard to which sqlite conforms ?
Some follow up and thank you all for looking at this. Using this mornings trunk/current/head I do see the tests running well with these little exceptions : boe13$ pwd /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.006 ... build clean as usual :-) tests run nicely now until ... Can you run: ./testfixture test/journal3.test and post the output? Thanks. . . . . Time: zipfile2.test 44 ms SQLite 2019-11-21 20:24:04 ac080432b480062507452d3cdbe6c0f759e6f95b65d9862e0462017405ab2b8e 8 errors out of 250191 tests on boe13.genunix.com Linux 64-bit little-endian !Failures on these tests: journal3-1.2.1.1 journal3-1.2.1.4 journal3-1.2.2.1 journal3-1.2.2.4 journal3-1.2.3.1 journal3-1.2.3.4 journal3-1.2.4.1 journal3-1.2.4.4 All memory allocations freed - no leaks Maximum memory usage: 9267208 bytes Current memory usage: 0 bytes Number of malloc() : -1 calls gmake: *** [Makefile:1252: tcltest] Error 1 real 410.99 user 376.39 sys 20.77 boe13$ Should we be concerned or are these artifacts from trunk/head/current? ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Shell commands for controlling headers
On 11/23/19, Craig H Maynard wrote: > All, > > Could someone clarify the difference between the two sqlite3 shell commands > .header and .headers? > > The relevant documentation page: https://www.sqlite.org/cli.html > > On this page, .header is discussed in section 5 but does not appear in > Section 3. > Documentation fix https://www.sqlite.org/docsrc/info/a2762f031964e774 will appears in the next release. ".header" is an abbreviation for ".headers" and does exactly the same thing. > Thanks, > Craig > > -- > Craig H Maynard > Rhode Island, > ___ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Shell commands for controlling headers
All, Could someone clarify the difference between the two sqlite3 shell commands .header and .headers? The relevant documentation page: https://www.sqlite.org/cli.html On this page, .header is discussed in section 5 but does not appear in Section 3. Thanks, Craig -- Craig H Maynard Rhode Island, ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Concurrency Question
On 23/11/62 17:02, Mario M. Westphal wrote: I have an issue with concurrency. This may be the intended behavior of SQLite. Or I'm doing something wrong. If somebody could shed a light, I would be thankful. I compile and use SQLite on Windows with VStudio. I compile it with SQLITE_THREADSAFE=1 At runtime, I use sqlite3_open_v2 () and set the flag SQLITE_OPEN_NOMUTEX. I use SQLite in WAL mode. My application uses several threads. Each thread opens its own database connection. Two threads run in parallel. Thread A does a lengthy UPDATE to table_A (prepared statement). This update takes, say, 5 seconds. Thread B uses a prepared statement to SELECT data from an unrelated table_B. Thread_B is blocked seconds in sqlite3Step because lockBtreeMutex() blocks in a mutex. I did not expect this. Why is thread_B blocked when doing a read just because SQLite is writing to another table? Is this the expected behavior or am I doing something stupid in my code. And if so, what to check? This should only happen if you are using shared-cache mode. Don't use shared-cache mode. Dan. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] LIKE IN
Both queries will work like this:
DROP TABLE names;
CREATE TABLE names (name TEXT);
INSERT INTO names VALUES ('Alex');
INSERT INTO names VALUES ('Alexander');
INSERT INTO names VALUES ('Alexandra');
INSERT INTO names VALUES ('Rob');
INSERT INTO names VALUES ('Rhobin'); -- should not match
INSERT INTO names VALUES ('Robert');
CREATE TABLE queries (query TEXT);
INSERT INTO queries VALUES ('Alex');
INSERT INTO queries VALUES ('Rob');
SELECT name from names t JOIN queries q ON t.name LIKE '%'||q.query||'%';
SELECT name from names
where exists (
select query from queries
where names.name like '%'||query||'%'
);
On Sat, 23 Nov 2019 at 11:34, Gert Van Assche wrote:
> I think this will work:
>
> INSERT INTO queries VALUES ('Alex');
> INSERT INTO queries VALUES ('Rob');
>
> select * from names
> where exists (
> select query from queries
> where names.name like '%'||query||'%'
> );
>
> On Fri, 22 Nov 2019 at 15:19, David Raymond
> wrote:
>
>> Or alternatively something like:
>>
>> select * from table
>> where exists (
>> select query from queries
>> where table.name like query
>> );
>>
>> ___
>> sqlite-users mailing list
>> sqlite-users@mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] LIKE IN
I think this will work:
INSERT INTO queries VALUES ('Alex');
INSERT INTO queries VALUES ('Rob');
select * from names
where exists (
select query from queries
where names.name like '%'||query||'%'
);
On Fri, 22 Nov 2019 at 15:19, David Raymond
wrote:
> Or alternatively something like:
>
> select * from table
> where exists (
> select query from queries
> where table.name like query
> );
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Concurrency Question
I have an issue with concurrency. This may be the intended behavior of SQLite. Or I'm doing something wrong. If somebody could shed a light, I would be thankful. I compile and use SQLite on Windows with VStudio. I compile it with SQLITE_THREADSAFE=1 At runtime, I use sqlite3_open_v2 () and set the flag SQLITE_OPEN_NOMUTEX. I use SQLite in WAL mode. My application uses several threads. Each thread opens its own database connection. Two threads run in parallel. Thread A does a lengthy UPDATE to table_A (prepared statement). This update takes, say, 5 seconds. Thread B uses a prepared statement to SELECT data from an unrelated table_B. Thread_B is blocked seconds in sqlite3Step because lockBtreeMutex() blocks in a mutex. I did not expect this. Why is thread_B blocked when doing a read just because SQLite is writing to another table? Is this the expected behavior or am I doing something stupid in my code. And if so, what to check? ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
