Re: [sqlite] wal mode

Even in rollback journal mode, it is not universally safe to use normal file operations on a SQLite database. See section 1.3 and 1.4 of https://www.sqlite.org/howtocorrupt.html If you want to use normal file system operations (or any type of manipulation not using the SQLite library) on an

Re: [sqlite] wal mode

On Fri, 6 Dec 2019 at 19:06, Simon Slavin wrote: > On 6 Dec 2019, at 6:39pm, MM wrote: > > > So it suffices that I run "PRAGMA journal_mode=WAL;" once from say the > sqlite3 cli, for all future connections from any tool will use WAL mode for > this database file? > > Correct. > > > What happens

Re: [sqlite] wal mode

On 6 Dec 2019, at 6:39pm, MM wrote: > So it suffices that I run "PRAGMA journal_mode=WAL;" once from say the > sqlite3 cli, for all future connections from any tool will use WAL mode for > this database file? Correct. > What happens when 2 processes that have had their connection open for a

Re: [sqlite] wal mode

"So it suffices that I run "PRAGMA journal_mode=WAL;" once from say the sqlite3 cli, for all future connections from any tool will use WAL mode for this database file?" Yup, the journal mode is stored in the database header. So the pragma will update the file's header, and any new connection

[sqlite] wal mode

Hello 3.26.0 From https://www.sqlite.org/wal.html, 3.3 I understand that "The persistence of WAL mode means that applications can be converted to using SQLite in WAL mode without making any changes to the application itself. One has merely to run "PRAGMA journal_mode=WAL;" on the database file(s)

Re: [sqlite] WAL mode much slower in certain use cases

On Behalf Of Andrew Cunningham Sent: Monday, July 01, 2019 2:04 PM To: SQLite Maillist Subject: [sqlite] WAL mode much slower in certain use cases I am using SQLite 3.24.0, as a single user persistent data store for storing simulation data. The database can grow to many gigabytes as the software can in

[sqlite] WAL mode much slower in certain use cases

I am using SQLite 3.24.0, as a single user persistent data store for storing simulation data. The database can grow to many gigabytes as the software can ingest a lot of binary data which I store as multiple BLOBs. In the following example I am reading several 22GB of data into the DB. Times

Re: [sqlite] wal

On Friday, 28 June, 2019 07:37, Thomas Kurz wrote: >> A WAL file left behind is a sign of a problem in the app which >should be corrected. >I have exactly this problem and don't like the SHM and WAL files >being left behind. I have even tried "pragma wal_checkpoint(full)" >before closing the

Re: [sqlite] wal

Haha :) Thanks for the insight. Hadn't looked at it that way. Ingo On 28-6-2019 11:52, Warren Young wrote: > You’ve basically got it backwards. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org

Re: [sqlite] wal

> A WAL file left behind is a sign of a problem in the app which should be > corrected. I have exactly this problem and don't like the SHM and WAL files being left behind. I have even tried "pragma wal_checkpoint(full)" before closing the connection, but there are still situations where the

Re: [sqlite] wal

On Jun 28, 2019, at 2:12 AM, ingo wrote: > > I see a wal file being created and deleted. Just for my > understanding, would it be of advantage to have a second persistent > connection just for keeping the wal alive? You’ve basically got it backwards. It’s a *good thing* when the WAL file

Re: [sqlite] wal

Hi, THe most persists after it has been set. The file comes and goes as needed. I seem to remember there are some caveats in the manual about what directory permissions are required and what happens when you can write the journal file and the database file but not the directory that contains

[sqlite] wal

From the docs, "The WAL journaling mode uses a write-ahead log instead of a rollback journal to implement transactions. The WAL journaling mode is persistent; after being set it stays in effect across multiple database connections and after closing and reopening the database." When using 'single

Re: [sqlite] WAL grows without bounds, short concurrent writes & reads

Awww sadness. Regardless, thanks for the update. > On Mar 29, 2019, at 11:07 AM, Richard Hipp wrote: > > On 3/29/19, Joshua Wise wrote: >> Dan, are there any plans to merge the wal2 branch into the trunk? > > No, not at this time. > > > -- > D. Richard Hipp > d...@sqlite.org >

Re: [sqlite] WAL grows without bounds, short concurrent writes & reads

On 3/29/19, Joshua Wise wrote: > Dan, are there any plans to merge the wal2 branch into the trunk? No, not at this time. -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org

Re: [sqlite] WAL grows without bounds, short concurrent writes & reads

Dan, are there any plans to merge the wal2 branch into the trunk? > On Mar 29, 2019, at 7:10 AM, Dan Kennedy wrote: > > > There's code here, if you want to experiment with it: > > https://sqlite.org/src/timeline?r=wal2 > > Docs: > > https://sqlite.org/src/artifact/a807405a05e19a49 > >

Re: [sqlite] WAL grows without bounds, short concurrent writes & reads

There's code here, if you want to experiment with it:   https://sqlite.org/src/timeline?r=wal2 Docs:   https://sqlite.org/src/artifact/a807405a05e19a49 Dan. On 29/3/62 01:33, Florian Uekermann wrote: Hi, A very simple reproducer bash script using the sqlite3 CLI is appended at the end.

[sqlite] WAL grows without bounds, short concurrent writes & reads

Hi, A very simple reproducer bash script using the sqlite3 CLI is appended at the end. I am using WAL mode in a setting with sequential writes and many concurrent reads. Due to WAL mode the readers don't get blocked, which is great and since writes are sequential, they never get blocked

Re: [sqlite] -wal and -shm files left behind by libsqlite3.dylib

This is expected behaviour. As Richard guessed, the system libsqlite3.dylib is built with SQLITE_ENABLE_PERSIST_WAL. For Darwin systems, the compromise of keeping the extra 4MiB (max) file around is generally worth the reduced I/O overhead that results from creating, resizing, and unlinking

Re: [sqlite] -wal and -shm files left behind by libsqlite3.dylib

Am Mo., 28. Jan. 2019 um 20:01 Uhr schrieb Richard Hipp : > On 1/28/19, Carsten Müncheberg wrote: > > When loading and using /usr/lib/libsqlite3.dylib (3.19.3) which is > shipped > > with MacOS 10.13.6 I noticed that the -wal and -shm files are not deleted > > when closing the last connection to

Re: [sqlite] -wal and -shm files left behind by libsqlite3.dylib

On 1/28/19, Carsten Müncheberg wrote: > When loading and using /usr/lib/libsqlite3.dylib (3.19.3) which is shipped > with MacOS 10.13.6 I noticed that the -wal and -shm files are not deleted > when closing the last connection to a database. I tested this with the > sqlite3 command line tool. It

[sqlite] -wal and -shm files left behind by libsqlite3.dylib

When loading and using /usr/lib/libsqlite3.dylib (3.19.3) which is shipped with MacOS 10.13.6 I noticed that the -wal and -shm files are not deleted when closing the last connection to a database. I tested this with the sqlite3 command line tool. It does not happen when I compile and link SQLite

Re: [sqlite] WAL mode readonly errors to SELECT statements

The sensible permissions in this case would probably be rw-rw-r-- with the same group as the service and owned by the service group. That is how group permissions were designed to work. > > ___ sqlite-users mailing list

Re: [sqlite] WAL mode readonly errors to SELECT statements

Thanks for the hint about pragma QUERY_ONLY, that might work but we will have to rethink the database file management. The database is currently owned by root and has sensible unix permissions of rw, r, r (ie only root has write permission) We can't run the intended service as root because that

Re: [sqlite] WAL mode readonly errors to SELECT statements

On 24 Jan 2019, at 2:37am, Robert Searle wrote: > occasionally get either > SQLITE_READONLY_RECOVERY or SQLITE_READONLY_CANTINIT responses to select > statements No programmer should be seeing these. They indicate low-level errors that cannot be handled in a systematic manner. Rather than

Re: [sqlite] WAL mode readonly errors to SELECT statements

Robert Searle wrote: > We have recently started trying to provide read-only access to the database > (service run as user with group/other read access permissions under Linux, > service not database owner) and occasionally get either > SQLITE_READONLY_RECOVERY or SQLITE_READONLY_CANTINIT responses

[sqlite] WAL mode readonly errors to SELECT statements

Hi, I have an sqlite3 database (version 3.25.3) in tmpfs which has many readers and writers. The database is running in WAL mode and seems to work efficiently in that mode. Since the database files are in a memory based file-system, we don't care about the usual corruption on power-cycle issues

Re: [sqlite] WAL mode for in-memory databases?

That doesn't sound healthy at all. If your application dies, what happens to the database? What if something rogue starts hitting it and just chews up your memory? IMO, Mem databases should be short lived and treated simply as an intentional cache. I get they're fast, but, long term life for a

Re: [sqlite] WAL mode for in-memory databases?

It would also be very helpful if more control about in-memory-databases was available. As far as I have understood, an in-memory database is deleted when the last connection closes. This requires me to always hold a connection to an in-memory database even if don't need it right now. Maybe one

Re: [sqlite] WAL mode for in-memory databases?

I’m very interested in the answer to this as I was planning on do the exact same thing.  Not sure my app would even be able to function without WAL mode. Brian Macy On Jan 14, 2019, 8:28 AM -0500, Dominique Devienne , wrote: > On Mon, Jan 14, 2019 at 2:23 PM Wout Mertens wrote: > > > AFAIK,

Re: [sqlite] WAL mode for in-memory databases?

On Mon, Jan 14, 2019 at 2:23 PM Wout Mertens wrote: > AFAIK, your best bet is to put a file db on a ramdisk (tmpfs). That's not a very portable solution, and a work-around at best. I don't see anything technical that would prevent WAL to work for ":memory:". "Shared-memory" "in-process" is

Re: [sqlite] WAL mode for in-memory databases?

e deemed not useful for in-memory? > i.e. is there a work-around that makes WAL-mode in-memory superfluous? > Or it's not superfluous and not supported, but could technically be > supported? > > Thanks for any insights. --DD > > [1] > > https://stackoverflow.com/quest

[sqlite] WAL mode for in-memory databases?

://stackoverflow.com/questions/28358153/sqlite-wal-mode-in-memory-database-with-private-cache ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] WAL file size increase

On 14 Nov 2018, at 4:20am, Sharma, Tanuj [AUTOSOL/FMP/IN] wrote: > I want to know why auto_checkpoint is not working when there is no Primary > Key in the table. If, during your testing, you're using existing database files, please create new ones each time. Can you please publish your

Re: [sqlite] WAL file size increase

On 11/13/18, Sharma, Tanuj [AUTOSOL/FMP/IN] wrote: > I have observed that when I don't have any primary key in the database table > then WAL auto_checkpoint doesn't work That's surprising because the WAL logic does not have anything to do with primary keys. Those are two completely independent

[sqlite] WAL file size increase

Dear SQL Developers / Users, I am using Sqlite3 in our project. My database has journal_mode set to WAL and has one writer & multiple readers. During normal mode of operation, only writing process is accessing database and there is no active reader connection I have observed that when I don't

Re: [sqlite] wal-mode and checkpoint

2018-09-02 17:31 GMT+02:00 Simon Slavin : > On 2 Sep 2018, at 2:43pm, Cecil Westerhof wrote: > > > When I do in sqlitebrowser: > >PRAGMA TABLE_INFO(messages) > > Just for peace of mind, since you are reporting unexpected behaviour, > please run an integrity_check. > As expected that gave

Re: [sqlite] wal-mode and checkpoint

On 2 Sep 2018, at 2:43pm, Cecil Westerhof wrote: > When I do in sqlitebrowser: >PRAGMA TABLE_INFO(messages) Just for peace of mind, since you are reporting unexpected behaviour, please run an integrity_check. Certain cleaning-up jobs are done only when the last connection to the database

[sqlite] wal-mode and checkpoint

I changed from the default delete mode to wal mode. I had some strange results, but it is working now. One of the programs is a service and can run for weeks. That is why I decided to call every hour: PRAGMA WAL_CHECKPOINT(TRUNCATE) I was wondering what people on this list thought about

[sqlite] Wal index format questions

Hello, thanks for the good documentation of the various database file formats. The wal index one is a bit unclear to me in a few spots, maybe someone can help me out? https://sqlite.org/walformat.html 2.1. The WAL-Index Header there is a second copy of the WAL index information, but it's not

Re: [sqlite] WAL and pragma uncommitted

On 02/02/2018 10:00 PM, Hannah Massey wrote: Does anybody know why I would be getting SQLITE_BUSY when closing the database connection in each thread even though I have finalized all prepared statements and am not doing any outstanding commands on the database? I have tests that need to copy the

Re: [sqlite] WAL and pragma uncommitted

Does anybody know why I would be getting SQLITE_BUSY when closing the database connection in each thread even though I have finalized all prepared statements and am not doing any outstanding commands on the database? I have tests that need to copy the database file once the application has

Re: [sqlite] WAL and pragma uncommitted

ok thanks. So looks like I'm going to try WAL mode with one connection to the database per thread and accessing the database using SQLITE_OPEN_NOMUTEX., no shared-cache mode, no pragma read_uncommitted. Thanks for the advice. On 20 January 2018 at 19:49, Dan Kennedy wrote:

Re: [sqlite] WAL and pragma uncommitted

On 01/19/2018 11:26 PM, Hannah Massey wrote: Currently we access a single SQLite database in a single thread but I am working on changing this as performance has become a real problem. We will be using WAL mode and there will be one thread for writes and multiple threads for reads. For many

Re: [sqlite] WAL and pragma uncommitted

On 19 Jan 2018, at 4:46pm, Deon Brewis wrote: > If you start with: > INSERT INTO Woz(Foo, Bar) Values(1,1) > > And a (normal) writer thread updates the 2 columns: > UPDATE Woz SET Foo=2, Bar=2 > > Can a read_uncommitted thread read the value from the row as: > Foo=1, Bar=2

Re: [sqlite] WAL and pragma uncommitted

Deon Brewis wrote: > What is the level of consistency (or rather inconsistency) for > read_uncommitted? In read_uncommited mode, read-only transactions to not take the database file lock. However, most sqlite3_xxx() function calls still lock the in-memory database object(s) (this is required

Re: [sqlite] WAL and pragma uncommitted

Hannah Massey wrote: > If I use separate connections for the reading threads then is there an > advantage to using "shared cache" for those connections? The shared cache would be useful to reduce memory usage (which should not be a concern except in embedded systems), but concurrent accesses to

Re: [sqlite] WAL and pragma uncommitted

a read_uncommitted read cause a crash? - Deon -Original Message- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Simon Slavin Sent: Friday, January 19, 2018 8:36 AM To: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> Subject: Re: [sqlite] WAL and

Re: [sqlite] WAL and pragma uncommitted

ok thanks for your advice. If I use separate connections for the reading threads then is there an advantage to using "shared cache" for those connections? On 19 January 2018 at 16:35, Simon Slavin wrote: > On 19 Jan 2018, at 4:26pm, Hannah Massey

Re: [sqlite] WAL and pragma uncommitted

On 19 Jan 2018, at 4:26pm, Hannah Massey wrote: > Will #pragma uncommitted work in WAL mode and will it have the effect I'm > looking for (where the read will be faster because it can ignore the > recently written information in the WAL File) and simply use the database

[sqlite] WAL and pragma uncommitted

Currently we access a single SQLite database in a single thread but I am working on changing this as performance has become a real problem. We will be using WAL mode and there will be one thread for writes and multiple threads for reads. For many cases, speed will be of a priority and it will not

Re: [sqlite] WAL mode with readers and writers

On 20 Nov 2017, at 7:37pm, Jim Dossey wrote: > sqlite3_prepare("SELECT * FROM table;"); > while (sqlite3_step() == SQLITE_ROW) { > x = current_rowid(); > sqlite3_exec("UPDATE table SET value=1 WHERE rowid=x;"); > sleep(1); > } In SQLite, as in other SQL engines, all

Re: [sqlite] WAL mode with readers and writers

says a lot about anticipated traffic volume. >-Original Message- >From: sqlite-users [mailto:sqlite-users- >boun...@mailinglists.sqlite.org] On Behalf Of Jim Dossey >Sent: Monday, 20 November, 2017 12:37 >To: sqlite-users@mailinglists.sqlite.org >Subject: [sqlite] WAL mode wi

[sqlite] WAL mode with readers and writers

Thanks to feedback from Simon Slavin, I now understand how data_version works and have it working in my code.  But in my testing, I tried another situation to see what would happen with locking in WAL mode.  I have a process that does the following pseudo-code with a table:

Re: [sqlite] WAL checkpoint starved?

Den 2017-06-07 kl. 17:09, skrev Simon Slavin: On 7 Jun 2017, at 1:49pm, Daniel Polski wrote: Ok, have I understood this correctly: If doing a manual checkpoint with SQLITE_CHECKPOINT_TRUNCATE, that call will block for maximum the time set by the busy_timeout while

Re: [sqlite] WAL checkpoint starved?

On 7 Jun 2017, at 1:49pm, Daniel Polski wrote: > Ok, have I understood this correctly: > > If doing a manual checkpoint with SQLITE_CHECKPOINT_TRUNCATE, that call will > block for maximum the time set by the busy_timeout while trying to proceed. > If the busy timeout

Re: [sqlite] WAL checkpoint starved?

On 6/7/17, Daniel Polski wrote: > > > Den 2017-06-07 kl. 15:02, skrev Richard Hipp: >> On 6/7/17, Daniel Polski wrote: >>> Does the [TRUNCATE] checkpoint call lock out new requests which might >>> prohibit >>> checkpoint progress while waiting for

Re: [sqlite] WAL checkpoint starved?

Den 2017-06-07 kl. 15:02, skrev Richard Hipp: On 6/7/17, Daniel Polski wrote: Does the [TRUNCATE] checkpoint call lock out new requests which might prohibit checkpoint progress while waiting for the timeout? It prohibits new writers. New readers are allowed to

Re: [sqlite] WAL checkpoint starved?

On 6/7/17, Daniel Polski wrote: > Does the [TRUNCATE] checkpoint call lock out new requests which might prohibit > checkpoint progress while waiting for the timeout? It prohibits new writers. New readers are allowed to proceed. > What will happen with other connections

Re: [sqlite] WAL checkpoint starved?

Den 2017-06-05 kl. 17:48, skrev Simon Slavin: On 5 Jun 2017, at 1:45pm, Daniel Polski wrote: How do I make the checkpointing work like the above documentation describes? Set a timeout. Perhaps a very long one (one minute, which is what I use in some places). You

Re: [sqlite] WAL checkpoint starved?

On 5 Jun 2017, at 1:45pm, Daniel Polski wrote: > How do I make the checkpointing work like the above documentation describes? Set a timeout. Perhaps a very long one (one minute, which is what I use in some places). You can do this two ways:

Re: [sqlite] WAL checkpoint starved?

Den 2017-06-05 kl. 12:34, skrev Richard Hipp: On 6/5/17, Daniel Polski wrote: Den 2017-06-02 kl. 16:07, skrev Richard Hipp: and I thought that SQLITE_CHECKPOINT_TRUNCATE would force the checkpoint to completion. Do you have a busy callback handler registered

Re: [sqlite] WAL checkpoint starved?

On 6/5/17, Daniel Polski wrote: > > > Den 2017-06-02 kl. 16:07, skrev Richard Hipp: >>> >>> and I thought that SQLITE_CHECKPOINT_TRUNCATE would force the checkpoint >>> to completion. >> Do you have a busy callback handler registered >>

Re: [sqlite] WAL checkpoint starved?

On Sun, Jun 4, 2017 at 10:54 PM, Daniel Polski wrote: > > Den 2017-06-02 kl. 16:07, skrev Clemens Ladisch: > >> Daniel Polski wrote: >> >>> Any ideas why I can end up with that large WAL file >>> >> Sounds like checkpoint starvation. >> Does the checkpoint call actually

Re: [sqlite] WAL checkpoint starved?

Den 2017-06-02 kl. 16:07, skrev Clemens Ladisch: Daniel Polski wrote: Any ideas why I can end up with that large WAL file Sounds like checkpoint starvation. Does the checkpoint call actually succeed? Unfortunately I don't know (adding a log message for that now). Any suggestions about how

Re: [sqlite] WAL checkpoint starved?

Den 2017-06-02 kl. 16:07, skrev Richard Hipp: On 6/2/17, Daniel Polski wrote: I've found something weird in a log from a client. Normally our WAL files are < 100kB, but in this log I noticed the file was >40MB. This was totally unexpected since we run this call every

Re: [sqlite] WAL checkpoint starved?

Daniel Polski wrote: > Any ideas why I can end up with that large WAL file Sounds like checkpoint starvation. Does the checkpoint call actually succeed? Regards, Clemens ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org

Re: [sqlite] WAL checkpoint starved?

On 6/2/17, Daniel Polski wrote: > I've found something weird in a log from a client. > Normally our WAL files are < 100kB, but in this log I noticed the file > was >40MB. This was totally unexpected since we run this call every minute: > > int val =

[sqlite] WAL checkpoint starved?

I've found something weird in a log from a client. Normally our WAL files are < 100kB, but in this log I noticed the file was >40MB. This was totally unexpected since we run this call every minute: int val = sqlite3_wal_checkpoint_v2(myDB->getDbPointer(), NULL, SQLITE_CHECKPOINT_TRUNCATE,

Re: [sqlite] WAL Checkpoint Blocking Behavior

Matt Fichman wrote: > I plan to disable WAL autocheckpoints and manually run permissive WAL > checkpoints on a second thread (as hinted at by the docs). > > If I do this, can a WAL checkpoint on the checkpoint thread still block or > significantly delay queries/updates from the main thread? The

[sqlite] WAL Checkpoint Blocking Behavior

Hi all, I'm trying to use SQLite in an asynchronous application that requires low/predictable latency access to the database. To achieve this is, I plan to disable WAL autocheckpoints and manually run permissive WAL checkpoints on a second thread (as hinted at by the docs). If I do this, can a

Re: [sqlite] WAL journal mode & sqlite3_backup_step()

> Le 15 févr. 2017 à 18:44, Clemens Ladisch a écrit : > > Olivier Mascia wrote: >> A good approach ... is to drive the backup by a single call to >> sqlite3_backup_step() > > This is indeed what you should do with WAL. > >> The only downside is that I loose the capability

Re: [sqlite] WAL journal mode & sqlite3_backup_step()

Olivier Mascia wrote: > A good approach ... is to drive the backup by a single call to > sqlite3_backup_step() This is indeed what you should do with WAL. > The only downside is that I loose the capability to monitor (or inform users > if needed) of the backup progress. That was never the

Re: [sqlite] WAL journal mode & sqlite3_backup_step()

> Le 15 févr. 2017 à 17:41, Olivier Mascia a écrit : > >> Le 15 févr. 2017 à 16:04, Olivier Mascia a écrit : >> >> Dear all, >> >> https://www.sqlite.org/c3ref/backup_finish.html#sqlite3backupstep makes it >> clear that connections (other than the one used

Re: [sqlite] WAL journal mode & sqlite3_backup_step()

> Le 15 févr. 2017 à 16:04, Olivier Mascia a écrit : > > Dear all, > > https://www.sqlite.org/c3ref/backup_finish.html#sqlite3backupstep makes it > clear that connections (other than the one used for the backup feature) which > writes in between calls to

[sqlite] WAL journal mode & sqlite3_backup_step()

Dear all, https://www.sqlite.org/c3ref/backup_finish.html#sqlite3backupstep makes it clear that connections (other than the one used for the backup feature) which writes in between calls to sqlite3_backup_step() will force the next sqlite3_backup_step() to start again the whole copy

Re: [sqlite] WAL mode

Yes, I am closing the DB before program exits. Like this: db.Close(). I am using Sqlite3 with Golang. Regards, Niti On Wed, Feb 8, 2017 at 11:08 PM, Jens Alfke wrote: > > > On Feb 8, 2017, at 9:21 AM, Niti Agarwal wrote: > > > > According to the

Re: [sqlite] WAL mode

On 8 Feb 2017, at 6:26pm, Jens Alfke wrote: > On Feb 8, 2017, at 9:46 AM, Simon Slavin wrote: > >> Does your program execute sqlite3_shutdown() and check to see whether it >> returns an error code ? > > Never noticed that function before … the docs

Re: [sqlite] WAL mode

> On Feb 8, 2017, at 9:46 AM, Simon Slavin wrote: > > Does your program execute sqlite3_shutdown() and check to see whether it > returns an error code ? Never noticed that function before … the docs say it’s "designed to aid in process initialization and shutdown on

Re: [sqlite] WAL mode

On 8 Feb 2017, at 5:21pm, Niti Agarwal wrote: > The databases I'm working with are write ahead logging (WAL) databases. > According to the SQLite documentation, the shm and wal files are supposed > to be deleted upon completion of the program. However, these files are >

Re: [sqlite] WAL mode

> On Feb 8, 2017, at 9:21 AM, Niti Agarwal wrote: > > According to the SQLite documentation, the shm and wal files are supposed > to be deleted upon completion of the program. Are you explicitly closing the database before your program exits? (In other words, I think

Re: [sqlite] WAL mode

On 2017/02/08 7:21 PM, Niti Agarwal wrote: The databases I'm working with are write ahead logging (WAL) databases. According to the SQLite documentation, the shm and wal files are supposed to be deleted upon completion of the program. However, these files are still there after execution of

[sqlite] WAL mode

The databases I'm working with are write ahead logging (WAL) databases. According to the SQLite documentation, the shm and wal files are supposed to be deleted upon completion of the program. However, these files are still there after execution of this program. The documentation says the files

Re: [sqlite] WAL and consistency

[mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Richard Hipp Sent: vendredi 3 février 2017 05:05 To: SQLite mailing list Subject: Re: [sqlite] WAL and consistency On 2/2/17, Rossel, Jonathan <jonathan.ros...@eta.ch> wrote: > Hi, > > Let me first congratulate you for the

Re: [sqlite] WAL and consistency

On 2/2/17, Rossel, Jonathan wrote: > Hi, > > Let me first congratulate you for the awesome product that SQLite is! I just > need a clarification with respect to a comment given in the docs > (http://sqlite.org/pragma.html#pragma_synchronous): > > "With synchronous=FULL in

[sqlite] WAL and consistency

Hi, Let me first congratulate you for the awesome product that SQLite is! I just need a clarification with respect to a comment given in the docs (http://sqlite.org/pragma.html#pragma_synchronous): "With synchronous=FULL in WAL mode, an additional sync operation of the WAL file happens after

Re: [sqlite] WAL pragma question

m: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Dan Kennedy Sent: Friday, October 28, 2016 5:21 AM To: sqlite-users@mailinglists.sqlite.org Subject: Re: [sqlite] WAL pragma question On 10/28/2016 03:16 AM, David Raymond wrote: I'm playing around with WAL mode

Re: [sqlite] WAL pragma question

e throwing me off. Of course I have to ask again here, am I understanding it correctly now? -Original Message- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Dan Kennedy Sent: Friday, October 28, 2016 5:21 AM To: sqlite-users@mailinglists.sqlite.org Su

Re: [sqlite] WAL pragma question

Also if you have any connections open, the journal may exist, so it doesn't have to constantly open and close it. On Fri, Oct 28, 2016 at 2:21 AM, Dan Kennedy wrote: > On 10/28/2016 03:16 AM, David Raymond wrote: > >> I'm playing around with WAL mode here for the first

Re: [sqlite] WAL pragma question

On 10/28/2016 03:16 AM, David Raymond wrote: I'm playing around with WAL mode here for the first time, along with some of the pragmas, and I'm getting some weird results. I was hoping someone could let me know if I'm missing something, or if yes, it is indeed weird. For starters, I'm looking

[sqlite] WAL pragma question

I'm playing around with WAL mode here for the first time, along with some of the pragmas, and I'm getting some weird results. I was hoping someone could let me know if I'm missing something, or if yes, it is indeed weird. For starters, I'm looking at the journal_size_limit pragma.

Re: [sqlite] [WAL] Querying/Finding out the WAL size (in pages) without trying to checkpoint

On 20 Sep 2016, at 2:39pm, Jose Arroyo wrote: > However, this writer process has no control over the reader processes, so > checkpoints may not necessary complete successfully ("If another connection > has a read transaction open, then the checkpoint cannot reset the

Re: [sqlite] [WAL] Querying/Finding out the WAL size (in pages) without trying to checkpoint

On 20 September 2016 at 14:29, Simon Slavin wrote: > > On 20 Sep 2016, at 8:59am, Jose Arroyo wrote: > > > My current issue is that I'm encountering WAL checkpoint starvation and > I'm > > trying to figure out a way to create checkpoint gaps

Re: [sqlite] [WAL] Querying/Finding out the WAL size (in pages) without trying to checkpoint

On 20 Sep 2016, at 8:59am, Jose Arroyo wrote: > My current issue is that I'm encountering WAL checkpoint starvation and I'm > trying to figure out a way to create checkpoint gaps only when needed. Can I ask why you're trying to have as few checkpoints as possible ?

Re: [sqlite] [WAL] Querying/Finding out the WAL size (in pages) without trying to checkpoint

Please let me know if this works for you - I've never tried it so at the moment it's just an idea :) Paul www.sandersonforensics.com skype: r3scue193 twitter: @sandersonforens Tel +44 (0)1326 572786 http://sandersonforensics.com/forum/content.php?195-SQLite-Forensic-Toolkit -Forensic Toolkit for

Re: [sqlite] [WAL] Querying/Finding out the WAL size (in pages) without trying to checkpoint

The writer process doesn't ever do "truncating" checkpoints, even if it does handle checkpoints manually. I'm starting to realize that truncating checkpoints are a good idea, especially after going through "checkpoint starvation" moments... In that case, I think I could make your suggestion work.

Re: [sqlite] [WAL] Querying/Finding out the WAL size (in pages) without trying to checkpoint

From within SQLite - I don't know if its possible. But if you can query the WAL file size you should be able to determine the number of pages easily enough. pages = (walfilesize-32)/(DBpagesize+24) the only caveats I can think of are: The WAL file is not truncated after a checkpoint so you

[sqlite] [WAL] Querying/Finding out the WAL size (in pages) without trying to checkpoint

From looking at the source code, it seems to me that the values returned on wal_hooks come from some sqlite's internal variables so it doesn't seem to be possible to query the DB for it. I suspect that the WAL size can be calculated from the WAL index file somehow, but I don't really grok how it

Re: [sqlite] Redundant open *.sqlite-wal file

...@mailinglists.sqlite.org] On Behalf Of Richard Hipp Sent: Monday, July 11, 2016 6:13 AM To: SQLite mailing list Subject: Re: [sqlite] Redundant open *.sqlite-wal file On 7/11/16, pavel.pimenov <pavel.pime...@gmail.com> wrote: > Hi > > journal_mode=PERSIST ! but sqlite 3.13.0 tries to open a file

Re: [sqlite] Redundant open *.sqlite-wal file

On 7/11/16, pavel.pimenov <pavel.pime...@gmail.com> wrote: > Hi > > journal_mode=PERSIST ! but sqlite 3.13.0 tries to open a file > *.sqlite-wal SQLite does not know the journal mode until it has opened the database. And it cannot safely open the database with

  1   2   3   4   5   >