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 synchr
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 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,
>
ty, and then load it back onto ramdisk after. I suppose I
may have to exit WAL mode in order to perform that copy, making
checkpointing a very expensive operation for my app.
On Fri, 2017-12-29 at 16:48 +, Simon Slavin wrote:
>
> On 29 Dec 2017, at 4:34pm, Ian Freeman wrote:
>
>
losses at in-opportune times.
Thank you.
On Fri, 2017-12-29 at 11:17 -0500, Richard Hipp wrote:
> 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
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
for
6 matches
Mail list logo
