Its not a problem in SQLite. I need a feature enhancement. Currently in SQLite i can allocate memory in a block.
Example: 2.5MB memory for memsys5 memory pool. Here 2MB i am using for Mem Db and 0.5MB for heap and other DB cache. I want flexibility such that when i close mem db, the 2MB should be freed. For this I need to configure SQLite with 2 Memory blocks. One with 2MB and another 0.5MB. For doing this I have sent the modifications that needs to be done. Regards Shankar On Thu, Aug 27, 2009 at 4:40 PM, Pavel Ivanov <paiva...@gmail.com> wrote: > OK. So you have allocated memsys5 memory pool and now are complaining > that this memory is not returned to OS? > > Sorry, but it's not quite understandable what do you want to achieve, > what's the problem with it and how did you find that there's a > problem. > > Pavel > > On Thu, Aug 27, 2009 at 6:11 AM, shankar m<shankar.mah...@gmail.com> > wrote: > > I have allocated memory for SQLite heap and using memsys5 memory pool > > algorithm to manage the heap. So if free is called it will be added to > free > > list of memsys5 memory pool. > > > > Regards > > Shankar > > > > On Wed, Aug 26, 2009 at 7:51 PM, Pavel Ivanov <paiva...@gmail.com> > wrote: > > > >> And I mean that you're wrong in this vision. SQLite doesn't keep > >> memory in pools if it doesn't belong to cache necessary to some open > >> connection. At least SQLite calls free() which of course doesn't > >> necessarily mean that memory will be returned to OS. > >> > >> > >> Pavel > >> > >> On Wed, Aug 26, 2009 at 10:02 AM, shankar m<shankar.mah...@gmail.com> > >> wrote: > >> > I mean to say free to the OS so that it can use for other purpose. > >> > > >> > SQlite frees but maintains to the memory will be present in SQLite > memory > >> > pool or heap. Not to the OS. > >> > > >> > Regards > >> > Shankar > >> > > >> > On Wed, Aug 26, 2009 at 7:15 PM, Pavel Ivanov <paiva...@gmail.com> > >> wrote: > >> > > >> >> > SQLite currently does not support freeing of allocated memory > >> >> > unless it is shutdown. > >> >> > >> >> It seams to me that you're wrong in this conclusion or elaborate > >> >> please how did you come to it. > >> >> In fact SQLite always frees all memory related to connection > >> >> (including cache) when you close it. And you can clearly see it in > >> >> sources... > >> >> > >> >> > >> >> Pavel > >> >> > >> >> On Wed, Aug 26, 2009 at 12:57 AM, shankar m<shankar.mah...@gmail.com > > > >> >> wrote: > >> >> > Hi, > >> >> > > >> >> > I am using SQLite in a embedded system which has the following > >> databases > >> >> > 1. 64MB Flash stored Database for persistent storage > >> >> > 2. 2 MB In-Memory Database. > >> >> > > >> >> > When the Memory Database is closed the 2MB should be returned to > the > >> >> > operating system. The 2 MB will be reallocated when the system > wants > >> to > >> >> use > >> >> > the mem db. SQLite currently does not support freeing of allocated > >> memory > >> >> > unless it is shutdown. > >> >> > > >> >> > > >> >> > To implement the above requirement I am planning to do as follows > >> >> > > >> >> > In SQLite Page cache module i.e pcahe1.c handles the datbase > buffering > >> of > >> >> > both persistent storage and in-memory storage. > >> >> > To identify whether the database is mem or file there is a flag > >> >> bPurgeable > >> >> > in struct PCache1. > >> >> > > >> >> > The pages for cache are allocated in functions > >> >> > 1. pcache1AllocPage > >> >> > 2. pcache1FreePage > >> >> > > >> >> > Add 2 new configuration variables > >> >> > 1. SQLITE_CONFIG_MEMDB - Enables separate memory DB with the > default > >> >> > values > >> >> > 2. SQLITE_CONFIG_MEMSIZE- Configures the mem db with user > specified > >> >> > memory block. Similar to the config variable > >> >> > SQLITE_CONFIG_PAGECACHE > >> >> > > >> >> > Using bPurgeable in pcache1AllocPage identify the mem db, If memdb > >> then > >> >> use > >> >> > the mem block specified by the user. > >> >> > The algorithm for the page allocation will be same as the list > >> >> > implementation present for the SQLITE_CONFIG_PAGECACHE > >> >> > > >> >> > Please provide comments or suggestion. > >> >> > > >> >> > Thanks > >> >> > Shankar > >> >> > _______________________________________________ > >> >> > sqlite-users mailing list > >> >> > sqlite-users@sqlite.org > >> >> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > >> >> > > >> >> _______________________________________________ > >> >> sqlite-users mailing list > >> >> sqlite-users@sqlite.org > >> >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > >> >> > >> > _______________________________________________ > >> > sqlite-users mailing list > >> > sqlite-users@sqlite.org > >> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > >> > > >> _______________________________________________ > >> sqlite-users mailing list > >> sqlite-users@sqlite.org > >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > >> > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@sqlite.org > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
