Re: [sqlite] sqlite Commit C API

2012-05-20 Thread Jay A. Kreibich 
On Sun, May 20, 2012 at 01:26:48PM +, Black, Michael (IS) scratched on the 
wall:
> Hmmm...our math is a bit different...

  Yeah, your math is wrong...  8-)

> A 1,000 RPM disk would take 1ms to spin around once 

  A 1,000 RPS disk would, but not a 1,000 RPM disk.

> I believe my original point stands...if your fsync() does nothing
> you'll see something close to zero all the time.

  Agreed.  I only meant to point out that when we're taking about
  physical I/O and spinning disks, "something close to zero" is
  measured in milliseconds, not fractions of a millisecond.

  If the OS is attempting to do the right thing, but the disk
  controller is lying about flushing the hardware cache, then you're
  likely to see something on the order of a millisecond or two.  In
  that case you need to communicate all the way out to the storage
  device, but it isn't doing anything.

  If you're actually writing data to a spinning disk, I would expect
  times to be varied, and average out to slightly more than half a
  rotation.  And rotations still take a LONG time in modern computing
  terms.

   -j

-- 
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Intelligence is like underwear: it is important that you have it,
 but showing it to the wrong people has the tendency to make them
 feel uncomfortable." -- Angela Johnson
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 3.7.12: segmentation fault in sqlite3ExprCodeTarget() when called from gnome-shell-3.4.1

2012-05-20 Thread Richard Hipp 
On Sun, May 20, 2012 at 3:04 PM, Alexandre Rostovtsev
wrote:

> (As reported at https://bugs.gentoo.org/show_bug.cgi?id=416563;
> originally sent to sqlite-dev, but an sqlite-dev list member informed
> me that I should report the problem to this mailing list instead.)
>
> After updating to sqlite-3.7.12, I have been getting crashes in
> gnome-shell-3.4.1 a few seconds after logging in to my desktop
> session. The attached gdb backtrace indicates that the immediate cause
> of the crash is a segfault is in sqlite code, in
> sqlite3ExprCodeTarget().
>

Can you please email to me the following:

(1) The database schema for the database in which the crash occurs.
(2) The complete text of the SQL statement being evaluated by
sqlite3Prepare() in frame 18 of thread 1.


>
> With sqlite-3.7.11, gnome-shell-3.4.1 works perfectly.
>
> This is on an amd64 gentoo linux machine with gcc-4.6.3 and
> glibc-2.15. I am also attaching the complete build log for
> sqlite-3.7.12 in case the precise manner in which it was built is
> useful for diagnosing the problem.
>
> -Alexandre Rostovtsev.
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>


-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] 3.7.12: segmentation fault in sqlite3ExprCodeTarget() when called from gnome-shell-3.4.1

2012-05-20 Thread Alexandre Rostovtsev 
(As reported at https://bugs.gentoo.org/show_bug.cgi?id=416563;
originally sent to sqlite-dev, but an sqlite-dev list member informed
me that I should report the problem to this mailing list instead.)

After updating to sqlite-3.7.12, I have been getting crashes in
gnome-shell-3.4.1 a few seconds after logging in to my desktop
session. The attached gdb backtrace indicates that the immediate cause
of the crash is a segfault is in sqlite code, in
sqlite3ExprCodeTarget().

With sqlite-3.7.11, gnome-shell-3.4.1 works perfectly.

This is on an amd64 gentoo linux machine with gcc-4.6.3 and
glibc-2.15. I am also attaching the complete build log for
sqlite-3.7.12 in case the precise manner in which it was built is
useful for diagnosing the problem.

-Alexandre Rostovtsev.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite related crash when starting Skrooge

2012-05-20 Thread Richard Hipp 
On Sat, May 19, 2012 at 3:35 PM, Guillaume DE BURE <
guillaume.deb...@gmail.com> wrote:

> Hi guys,
>
> I am one of the developpers of Skrooge, an Open Source application for
> personal finances management (http://skrooge.org). After upgrading SQLite
> to
> 3.7.12, our users report crashes upon starting the application :
> https://bugs.kde.org/show_bug.cgi?id=300183
>

Can you please send us your database schema?  An email attachment to
d...@sqlite.org will be fine.


>
> Apparently, switching back to 3.7.11 solves the issue. I could confirm the
> crash, and generated the attached backtrace. Can you please help us
> understand
> what is going on, and advise us on steps to take to solve the issue ?
>
> Thanks in advance :)
>
> Guillaume
>
> --
> Skrooge, a free, Open Source, personal finances software for linux, Mac OS,
> Windows
> http://skrooge.org
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>


-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLite related crash when starting Skrooge

2012-05-20 Thread Guillaume DE BURE 
Hi guys,

I am one of the developpers of Skrooge, an Open Source application for 
personal finances management (http://skrooge.org). After upgrading SQLite to 
3.7.12, our users report crashes upon starting the application :
https://bugs.kde.org/show_bug.cgi?id=300183

Apparently, switching back to 3.7.11 solves the issue. I could confirm the 
crash, and generated the attached backtrace. Can you please help us understand 
what is going on, and advise us on steps to take to solve the issue ?

Thanks in advance :)

Guillaume

-- 
Skrooge, a free, Open Source, personal finances software for linux, Mac OS, 
Windows
http://skrooge.orgApplication: Skrooge (skrooge), signal: Segmentation fault
Using host libthread_db library "/lib/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f09aaba1780 (LWP 30797))]

Thread 3 (Thread 0x7f0994fa6700 (LWP 30798)):
#0  0x7f09a7c0d8f4 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib/libpthread.so.0
#1  0x7f09a38c824c in ?? () from /usr/lib/libQtWebKit.so.4
#2  0x7f09a38c8379 in ?? () from /usr/lib/libQtWebKit.so.4
#3  0x7f09a7c09e0e in start_thread () from /lib/libpthread.so.0
#4  0x7f09a71371ed in clone () from /lib/libc.so.6

Thread 2 (Thread 0x7f09946a5700 (LWP 30799)):
#0  0x7f09a712f06f in poll () from /lib/libc.so.6
#1  0x7f09a1c14774 in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x7f09a1c14894 in g_main_context_iteration () from 
/usr/lib/libglib-2.0.so.0
#3  0x7f09a7fc11b6 in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /usr/lib/libQtCore.so.4
#4  0x7f09a7f91f8f in 
QEventLoop::processEvents(QFlags) () from 
/usr/lib/libQtCore.so.4
#5  0x7f09a7f92218 in 
QEventLoop::exec(QFlags) () from 
/usr/lib/libQtCore.so.4
#6  0x7f09a7e966f0 in QThread::exec() () from /usr/lib/libQtCore.so.4
#7  0x7f09a7e9968b in ?? () from /usr/lib/libQtCore.so.4
#8  0x7f09a7c09e0e in start_thread () from /lib/libpthread.so.0
#9  0x7f09a71371ed in clone () from /lib/libc.so.6

Thread 1 (Thread 0x7f09aaba1780 (LWP 30797)):
[KCrash Handler]
#5  sqlite3ExprCodeTarget (pParse=pParse@entry=0x1f9a948, pExpr=0x10d2e80, 
target=target@entry=19) at sqlite3.c:77533
#6  0x7f099e9450c7 in sqlite3ExprCodeTemp (pParse=pParse@entry=0x1f9a948, 
pExpr=, pReg=pReg@entry=0x7fff42621d68) at sqlite3.c:77625
#7  0x7f099e9441b3 in sqlite3ExprCodeTarget (pParse=pParse@entry=0x1f9a948, 
pExpr=0x7f09a73ee6a8, target=target@entry=57) at sqlite3.c:77540
#8  0x7f099e944ff6 in sqlite3ExprCodeExprList 
(pParse=pParse@entry=0x1f9a948, target=target@entry=57, 
doHardCopy=doHardCopy@entry=1, pList=, pList=) at sqlite3.c:78099
#9  0x7f099e9061e2 in updateAccumulator (pParse=pParse@entry=0x1f9a948, 
pAggInfo=pAggInfo@entry=0x7fff42622050) at sqlite3.c:98535
#10 0x7f099e942512 in sqlite3Select (pParse=pParse@entry=0x1f9a948, 
p=p@entry=0x1517b58, pDest=pDest@entry=0x7fff42622150) at sqlite3.c:99380
#11 0x7f099e943bb7 in sqlite3CodeSubselect (pParse=0x1f9a948, 
pExpr=0x1e2a3f8, rMayHaveNull=rMayHaveNull@entry=0, isRowid=isRowid@entry=0) at 
sqlite3.c:76496
#12 0x7f099e944b93 in sqlite3ExprCodeTarget (pParse=pParse@entry=0x1f9a948, 
pExpr=0x1e2a3f8, target=target@entry=10) at sqlite3.c:77384
#13 0x7f099e944ff6 in sqlite3ExprCodeExprList 
(pParse=pParse@entry=0x1f9a948, target=target@entry=4, 
doHardCopy=doHardCopy@entry=0, pList=, pList=) at sqlite3.c:78099
#14 0x7f099e905d6c in selectInnerLoop (pParse=0x1f9a948, p=0x1e74ef8, 
pEList=0x10bf688, srcTab=0, nColumn=0, pOrderBy=0x0, distinct=-1, 
pDest=0x7fff42622670, iContinue=-4, iBreak=-2) at sqlite3.c:95500
#15 0x7f099e94136c in sqlite3Select (pParse=pParse@entry=0x1f9a948, 
p=p@entry=0x1e74ef8, pDest=pDest@entry=0x7fff42622670) at sqlite3.c:98993
#16 0x7f099e95ddbe in sqlite3EndTable (pParse=pParse@entry=0x1f9a948, 
pCons=pCons@entry=0x0, pEnd=pEnd@entry=0x0, pSelect=0x1e74ef8) at 
sqlite3.c:83138
#17 0x7f099e95a7d6 in yy_reduce (yyruleno=33, yypParser=0x15ea458) at 
sqlite3.c:110405
#18 sqlite3Parser (yyp=yyp@entry=0x15ea458, yymajor=yymajor@entry=1, 
yyminor=..., pParse=pParse@entry=0x1f9a948) at sqlite3.c:46063
#19 0x7f099e95d1a2 in sqlite3RunParser (pParse=pParse@entry=0x1f9a948, 
zSql=zSql@entry=0x1e85188 "CREATE TABLE vm_category_display_tmp AS SELECT * 
FROM v_category_display_tmp", pzErrMsg=pzErrMsg@entry=0x7fff426229f8) at 
sqlite3.c:112436
#20 0x7f099e95ecf2 in sqlite3Prepare (db=db@entry=0x14cdf68, 
zSql=zSql@entry=0x1e85188 "CREATE TABLE vm_category_display_tmp AS SELECT * 
FROM v_category_display_tmp", nBytes=nBytes@entry=-1, 
saveSqlFlag=saveSqlFlag@entry=1, pReprepare=pReprepare@entry=0x0, 
ppStmt=ppStmt@entry=0x1e30090, pzTail=pzTail@entry=0x7fff42622ac8) at 
sqlite3.c:94657
#21 0x7f099e95ef79 in sqlite3LockAndPrepare (pzTail=0x7fff42622ac8, 
ppStmt=0x1e30090, pOld=0x0, saveSqlFlag=1, nBytes=-1, zSql=0x1e85188 "CREATE 
TABLE vm_category_display_tmp AS SELECT * FROM v_category_display_tmp", 
db=0x14cdf68) at sqlite3.c:94749
#22 sqlite3LockAndPr

Re: [sqlite] csv test cases (was Details On New Features)

2012-05-20 Thread Peter Haworth 
Donald,
I have a question about #9 of your test cases.  According to RFC 4180, #9
is an invalid record.  The RFC states "If fields are not enclosed with
double quotes, then

double quotes may not appear inside the fields."


However, I imported your test cases into Open Office, Excel, and
Numbers and the resulting spreadsheets all left the quotes in place in
that record.  To confuse matters even more, if I then exported those
spreadsheets as csv files, they all enlosed the string in quotes and
escaped the original quotes.


So I guess there's precedent for either case depending on how closely
you want to stick to the RFC.


Pete
lcSQL Software 



On Mon, May 7, 2012 at 9:00 AM,  wrote:

> Message: 17
> Date: Sun, 6 May 2012 20:00:51 -0400
> From: Donald Griggs 
> To: General Discussion of SQLite Database 
> Subject: Re: [sqlite] Details on New Features
> Message-ID:
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> Regarding:   What precisely are the
> "improvements" in handling of CSV inputs?
>
>
> Gabor, I don't know about "precisely" -- I'll let others on the list tell
> me where I'm off, but here's my take:
>
>
> A lot of strange things call themselves csv, but the change attempts to
> make the sqlite3 utility's CSV inputs perform a bit more closely to
> RFC4180.
> http://tools.ietf.org/html/rfc4180
>
> http://en.wikipedia.org/wiki/Comma-separated_values#Toward_standardization
>
> In particular, during CSV mode import:
>  -- Allow any field to be surrounded by double quote characters without
> those characters being considered part of the field data.
>  -- Allow fields to contain embedded commas (or other separators) when the
> field is surrounded by double quote characters.
>  -- Allow fields to span multiple lines if they are surrounded by double
> quote characters.
>  -- Allow the double quote character to be escaped by having two adjacent
> double quote characters. (But note that a field consisting solely of two
> double quote characters still represents an empty string field.)
>
>  -- On output in CSV mode, surround text fields with double quotes when
> needed.
>
>
> See check-in [93aa17d866]   http://www.sqlite.org/src/info/93aa17d866
>
> (By the way, I believe the sqlite3 command line utility (CLI) was intended
> to be more of a debug tool than a production component -- but it surely is
> useful!)
>
> For an example of CSV import, if I have file MyStuff.csv whose data is
> shown below between the barred lines below (words in square brackets [] are
> just my comments and were not present in the import file):
> ==
> 1,cat
> 2,"rat"[quotes are optional unless separator(s)
> embedded]
>3 ,"grey fox"  [extra whitespace will be handled differently
> when affinity is numeric]
> 4, spacedog[There's a space before and after spacedog --
> trust me]
> 5,o'possum
> 6,"big, bad, wolf"
> 7,"two-lined   [Fields can span lines]
> zebra"
> 8, [Second field empty. (Maybe I forgot to type
> "Missing lynx")]
> 9,imperial ("laughing") loon
> ==
>  Now I create a test database.
>
> C:\util>sqlite3 test.db
>
> SQLite version 3.7.11 2012-03-20 11:35:50
> Enter ".help" for instructions
> Enter SQL statements terminated with a ";"
>
> sqlite> /* Define a simple table t, comprised of an integer column and a
> text column */
> sqlite> Create table t ( id integer, animal);
>
> sqlite> /*  import the data above using csv mode */
> sqlite> .mode csv
> sqlite> .import MyStuff.csv   t
>
>
> sqlite> /* Show the table in CSV mode
> sqlite> select * from t;
> 1,cat
> 2,rat
> 3,"grey fox"
> 4," spacedog "
> 5,"o'possum"
> 6,"big, bad, wolf"
> 7,"two-lined
> zebra"
> 8,""
> 9,"imperial (""laughing"") loon"
> sqlite>
> sqlite>
> sqlite>
> sqlite> /* Try changing the separator and show it again in LIST mode */
> sqlite> .separator |
> sqlite> .mode list
> sqlite> select * from t;
> 1|cat
> 2|rat
> 3|grey fox
> 4| spacedog
> 5|o'possum
> 6|big, bad, wolf
> 7|two-lined
> zebra
> 8|
> 9|imperial ("laughing") loon
> sqlite>
>
> Does this answer your questions?
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] sqlite Commit C API

2012-05-20 Thread Igor Tandetnik 
Black, Michael (IS)  wrote:
> Hmmm...our math is a bit different...
> 
> A 1,000 RPM disk would take 1ms to spin around once

No it wouldn't.

> (there are 1000ms in a second, correct?)

Yes, but RPM stands for a revolution-per-*minute*. You are off by a factor of 
60.
-- 
Igor Tandetnik

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] sqlite Commit C API

2012-05-20 Thread Black, Michael (IS) 
Hmmm...our math is a bit different...

A 1,000 RPM disk would take 1ms to spin around once (there are 1000ms in a 
second, correct?)

10,000 RPM would take .1ms.

7200 RPM would take .138ms



And...if I reduce the buffer size to 1 byte I see this...around 2-3X of 
rotation time with the sleep enabled.

fsync time: 0.00040
fsync time: 0.00033
fsync time: 0.00028
fsync time: 0.00027
fsync time: 0.00027
fsync time: 0.00058
fsync time: 0.00032
fsync time: 0.00042
fsync time: 0.00029
fsync time: 0.00035
fsync time: 0.00033
fsync time: 0.00030
fsync time: 0.00027
fsync time: 0.00027

Remove the sleep though and the times drop to .04ms which indicates the my 
fsync() is probably write cached.  I'm a telecommuter so I can't check the BIOS 
settings on this particular boxbut I'll bet it's write cached.



I believe my original point stands...if your fsync() does nothing you'll see 
something close to zero all the time.



Michael D. Black

Senior Scientist

Advanced Analytics Directorate

Advanced GEOINT Solutions Operating Unit

Northrop Grumman Information Systems


From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on 
behalf of Jay A. Kreibich [j...@kreibi.ch]
Sent: Sunday, May 20, 2012 7:53 AM
To: General Discussion of SQLite Database
Subject: EXT :Re: [sqlite] sqlite Commit C API

On Sun, May 20, 2012 at 12:04:33PM +, Black, Michael (IS) scratched on the 
wall:

> Another more indirect way to test is this utility:
>
> http://kerneltrap.org/mailarchive/linux-ext4/2009/3/22/5215824
>
> Which...if your fsync doesn't work at all will return something really
> close to zero.
>
> On my RedHat system I get this which indicates fsync actually takes a
> little of time...therefore it must be doing somethingalthough it
> doesn't prove that it's actually on the disk yet.
>
> fsync time: 0.0022
> fsync time: 0.0019
> fsync time: 0.0019
> fsync time: 0.0022
> fsync time: 0.0019
> fsync time: 0.0019
> fsync time: 0.0020
> fsync time: 0.0020

  Assuming this is spinning disk, that takes a *very* little amount of
  time...  A 10K RPM disk takes about 6 ms to spin around once.  A more
  conventional 7600 RPM drive takes 7.9 ms.  Ignoring seek times, device
  I/O times, and all the rest, it should still take, on average, about
  half those times just for the right sector to come around underneath
  the heads.  But that's just an average-- it should vary from write to
  write.  I doubt sleep() is accurate enough to keep the program in sync
  with the spindle rotation over a full second.

  That doesn't seem to match the consistent, 2 ms times you're seeing.
  Both the low time, and the consistency of them, make me suspect of
  these numbers-- unless it is an SSD device.

> And I do believe if you take the sleep() out of the loop that you should
> see constant times.

  I would suspect that loop is faster than a disk rotation, so assuming
  there isn't much other I/O going on in the system, I would also
  expect to see somewhat more consistent times without the sleep().

> Otherwise you'll see a much bigger time once in a
> while when you overrun the buffers and it has to pause to really flush.
>
> Again...on my system I see this...one value 3 times as large as the
> others...suspicious.

  Yes... but not so much that one number is larger, as the fact that all
  the other numbers are consistently small.

  Of course, you can also see large changes in fsync() times if
  anything else on the system needs to do I/O.   Again, assuming we're
  talking about spinning disk, if you have random I/O from other
  processes, you're going to see seeks and random rotation delays that
  should be even larger than this.

   -j

> sort fsync.dat | tail -n 5
> fsync time: 0.0025
> fsync time: 0.0025
> fsync time: 0.0026
> fsync time: 0.0027
> fsync time: 0.0059
>

--
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Intelligence is like underwear: it is important that you have it,
 but showing it to the wrong people has the tendency to make them
 feel uncomfortable." -- Angela Johnson
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] sqlite Commit C API

2012-05-20 Thread Jay A. Kreibich 
On Sun, May 20, 2012 at 12:04:33PM +, Black, Michael (IS) scratched on the 
wall:

> Another more indirect way to test is this utility:
> 
> http://kerneltrap.org/mailarchive/linux-ext4/2009/3/22/5215824
> 
> Which...if your fsync doesn't work at all will return something really
> close to zero.
> 
> On my RedHat system I get this which indicates fsync actually takes a
> little of time...therefore it must be doing somethingalthough it
> doesn't prove that it's actually on the disk yet.
> 
> fsync time: 0.0022
> fsync time: 0.0019
> fsync time: 0.0019
> fsync time: 0.0022
> fsync time: 0.0019
> fsync time: 0.0019
> fsync time: 0.0020
> fsync time: 0.0020

  Assuming this is spinning disk, that takes a *very* little amount of
  time...  A 10K RPM disk takes about 6 ms to spin around once.  A more
  conventional 7600 RPM drive takes 7.9 ms.  Ignoring seek times, device
  I/O times, and all the rest, it should still take, on average, about
  half those times just for the right sector to come around underneath
  the heads.  But that's just an average-- it should vary from write to
  write.  I doubt sleep() is accurate enough to keep the program in sync
  with the spindle rotation over a full second.

  That doesn't seem to match the consistent, 2 ms times you're seeing.
  Both the low time, and the consistency of them, make me suspect of
  these numbers-- unless it is an SSD device.

> And I do believe if you take the sleep() out of the loop that you should
> see constant times.  

  I would suspect that loop is faster than a disk rotation, so assuming
  there isn't much other I/O going on in the system, I would also
  expect to see somewhat more consistent times without the sleep().

> Otherwise you'll see a much bigger time once in a
> while when you overrun the buffers and it has to pause to really flush.
>
> Again...on my system I see this...one value 3 times as large as the
> others...suspicious.

  Yes... but not so much that one number is larger, as the fact that all
  the other numbers are consistently small.

  Of course, you can also see large changes in fsync() times if
  anything else on the system needs to do I/O.   Again, assuming we're
  talking about spinning disk, if you have random I/O from other
  processes, you're going to see seeks and random rotation delays that
  should be even larger than this.

   -j

> sort fsync.dat | tail -n 5
> fsync time: 0.0025
> fsync time: 0.0025
> fsync time: 0.0026
> fsync time: 0.0027
> fsync time: 0.0059
> 

-- 
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Intelligence is like underwear: it is important that you have it,
 but showing it to the wrong people has the tendency to make them
 feel uncomfortable." -- Angela Johnson
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] sqlite Commit C API

2012-05-20 Thread Black, Michael (IS) 
If you can run perl on your ARM host try this utility to see if fsync() 
actually works -- this is a real end-to-end test that you pull the plug on and 
it will let you know if your disk file is where it's supposed to be and how 
many errors you had.

http://brad.livejournal.com/2116715.html



Another more indirect way to test is this utility:

http://kerneltrap.org/mailarchive/linux-ext4/2009/3/22/5215824



Which...if your fsync doesn't work at all will return something really close to 
zero.



On my RedHat system I get this which indicates fsync actually takes a little of 
time...therefore it must be doing somethingalthough it doesn't prove that 
it's actually on the disk yet.

fsync time: 0.0022
fsync time: 0.0019
fsync time: 0.0019
fsync time: 0.0022
fsync time: 0.0019
fsync time: 0.0019
fsync time: 0.0020
fsync time: 0.0020



And I do believe if you take the sleep() out of the loop that you should see 
constant times.  Otherwise you'll see a much bigger time once in a while when 
you overrun the buffers and it has to pause to really flush.

Again...on my system I see this...one value 3 times as large as the 
others...suspicious.

sort fsync.dat | tail -n 5
fsync time: 0.0025
fsync time: 0.0025
fsync time: 0.0026
fsync time: 0.0027
fsync time: 0.0059





Michael D. Black

Senior Scientist

Advanced Analytics Directorate

Advanced GEOINT Solutions Operating Unit

Northrop Grumman Information Systems
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] sqlite Commit C API

2012-05-20 Thread Baruch Burstein 
> On Thu, May 17, 2012 at 7:04 PM, Rajesh Kumar  wrote:
>
 int fsync( int fd ) { return 0; }
>
> fsync will expect an Integer pointer right. But sqlite pointer is of type
> sqlite3*. So how can fsync works on sqlite. What should I pass to fsync???
>
>
You don't need to call fsync(). Sqlite calls it internally to make sure no
corruption occurs. If it is broken on your system, then by extension any
software that depends on it working properly (such as sqlite) will be
broken, too.

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users