>Naturally, and of course. The point of my initial post was that I was
>still seeing sync operations with synch=NORMAL when I shouldn't have
>according to the below docs (now debatable whether they were actually
>written to disk or just the os cache). I purposely configured synch
>to
>NORMAL to
On 30 Dec 2017, at 4:38pm, Ian Freeman wrote:
> Naturally, and of course. The point of my initial post was that I was still
> seeing sync operations with synch=NORMAL when I shouldn't have according to
> the below docs (now debatable whether they were actually written to
On 30.12.2017 01:14, Keith Medcalf wrote:
One presumes that you mayhaps read the documentation?
"In WAL mode when synchronous is NORMAL (1), the WAL file is
synchronized before each checkpoint and the database file is
synchronized after each completed checkpoint and the WAL file header
is
ite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Ian Freeman
>Sent: Friday, 29 December, 2017 22:38
>To: SQLite mailing list
>Subject: Re: [sqlite] fsync on -wal still happening
>
>On Fri, 2017-12-29 at 22:18 +, Simon Slavin wrote:
>>
>> On 29 Dec 2017, at 7:07pm, Ian Fre
On Sat, 2017-12-30 at 05:40 +, Simon Slavin wrote:
> Accumulate your change commands in memory as text. Eventually
> execute them all inside BEGIN … COMMIT.
I like it; why didn't I think of it? Don't you love those moments?
The application would need severe retooling for reads unless I also
On 30 Dec 2017, at 5:37am, Ian Freeman wrote:
> Agreed, the defaults would be very safe. But I realize I never
> mentioned what my actual goal was: minimizing disk writes for a write-
> heavy application. That's why I want to run -wal out of memory, or set
>
On Fri, 2017-12-29 at 22:18 +, Simon Slavin wrote:
>
> On 29 Dec 2017, at 7:07pm, Ian Freeman wrote:
>
> > Thanks, Simon. Indeed I did see that option. But I'm concerned
> > about
> > maintaining integrity in the middle of an power-interrupted commit,
>
> This is not a
On 29 Dec 2017, at 7:07pm, Ian Freeman wrote:
> Thanks, Simon. Indeed I did see that option. But I'm concerned about
> maintaining integrity in the middle of an power-interrupted commit,
This is not a problem for either WAL mode or the older journal modes. If you
avoid
I believe the inotifywait does not actually wait for the fsync operation before
notifying.
Process A can write to a file, the OS can cache it without flushing to disk,
and a request by process B will be served directly from the cache. Therefore
the operating system can notify you of the change
Thanks, Simon. Indeed I did see that option. But I'm concerned about
maintaining integrity in the middle of an power-interrupted commit, so
I was hoping to leverage WAL's inverted behavior of not modifying the
database file directly until checkpoint time. The only thing left to
investigate is how
On 29 Dec 2017, at 4:34pm, Ian Freeman wrote:
> I see, then what I'm seeing is just normal behavior of the writes being
> flushed to disk. I read what I wanted to hear about synchronous=NORMAL
> delaying writes to the -wal file. Instead I'm going to see if I can
> move -wal
I see, then what I'm seeing is just normal behavior of the writes being
flushed to disk. I read what I wanted to hear about synchronous=NORMAL
delaying writes to the -wal file. Instead I'm going to see if I can
move -wal to a ramdisk and see how that will affect db integrity with
power losses at
On 12/28/17, Ian Freeman wrote:
> I have configured journal_mode=WAL, synchronous=NORMAL, and disabled
> autocheckpointing, and yet the -wal file is modified after every update
> operation...
That is correct. "sync" means forcing the data from the internal
operating-system
I have configured journal_mode=WAL, synchronous=NORMAL, and disabled
autocheckpointing, and yet the -wal file is modified after every update
operation...
That's not the documented behavior as I understand it. This smells like
a bug to me, but before I go that direction, is there an explanation
14 matches
Mail list logo