On 15-Aug-05, at 5:39 PM, D. Kettler wrote:
Project? DLL? Visual Studio? I said I was using Linux and g++
just link with full path to libsqlite3.a
example: gcc -o foo foo.o /usr/local/lib/libsqlite3.a
man gcc
ck
On 15-Aug-05, at 7:12 PM, D. Kettler wrote:
g++ -o kumacgen kumacgen.cpp /usr/lib/libsqlite3.a
add -lpthread to your link line.
ck
On 3-Sep-04, at 9:31 AM, Christian Smith wrote:
How often does the balancer run? Could the space for the balance
routine
be allocated with the sqlite structure? It is opaque anyway, and is
allocated only once, so there should be no penalty in performance over
the
current stack implementation, and
See check in 1937 which changes:
"Modify btree.c so that is allocates big data structures using malloc()
instead of allocating from the stack. Stack allocations cause problems
for embedded systems and pthreads implementations that only allocate a
limited amount of stack space."
You will need to
I noticed this as well, so I profiled my call and found sync was taking
forever. I removed the following fcntl call, rc = fcntl(fd,
F_FULLFSYNC, 0);. Performance was back to normal.
ck
On 21-Feb-05, at 10:39 AM, [EMAIL PROTECTED] wrote:
It is a trade off between guaranteed data integrity and performance.
If there happen to be a bunch of other apps writing to the disk when
you do a SQLite transaction, then all of that data has to be flushed
to the disk. As Domnic said, fsync
On 21-Feb-05, at 11:11 AM, [EMAIL PROTECTED] wrote:
OK -- so, you are willing to accept the risk of non-recoverable
database corruption in the event of power outage or other kinds of
catastrophic system failure (including the plug being pulled on a
FireWire drive without it being properly unmoun
7 matches
Mail list logo
