Sascha Sertel wrote:
> While our long lived prepared statements are reset many times throughout
> their lifecycle, there are several of them in use at the same time, and
> probably never in a state where all of them are reset. The statements feed
> a UI and are constantly refreshed, requeried, and
On Fri, Nov 22, 2013 at 10:10 AM, Sascha Sertel wrote:
>
> We actually hold a cache of prepared statements so we know which ones are
> open, maybe as an experiment I could try calling reset on all of them and
> see if that gives the checkpointer enough time to do its
On Nov 22, 2013 6:08 AM, "Simon Slavin" wrote:
>
>
> On 22 Nov 2013, at 1:24pm, Clemens Ladisch wrote:
>
> > Simon Slavin wrote:
> >> All statements are entirely enclosed in a transaction.
> >
> > No, automatic transactions start with the first
On 22 Nov 2013, at 1:24pm, Clemens Ladisch wrote:
> Simon Slavin wrote:
>> All statements are entirely enclosed in a transaction.
>
> No, automatic transactions start with the first sqlite3_step() and end
> with either sqlite3_reset() or sqlite3_finalize().
Thanks,
Simon Slavin wrote:
> All statements are entirely enclosed in a transaction.
No, automatic transactions start with the first sqlite3_step() and end
with either sqlite3_reset() or sqlite3_finalize().
Regards,
Clemens
___
sqlite-users mailing list
On 22 Nov 2013, at 7:39am, Sascha Sertel wrote:
> We also switched to WAL journaling mode a while ago and noticed that the
> WAL file just keeps growing bigger and bigger, and the checkpointer never
> seems to be able to write everything back into the main database file
On 11/22/2013 02:47 PM, Dan Kennedy wrote:
On 11/22/2013 02:39 PM, Sascha Sertel wrote:
Hello everybody,
the app I'm working on heavily relies on use and reuse of prepared
statements, many of them are reset many times but not finalized until
the
end of the application lifetime.
We also
7 matches
Mail list logo