should we upgrade pre-beta users to get incremental vacuum and page size of 4096? if you've run a build before bug #401985 and bug #385834 landed, then your places.sqlite file got created with a page size of 1024 and without support for incremental vacuuming. discussing this with sdwilsh a while back over email, he wrote: "we could handle that with a database schema update (move the file, open it, copy it into a new file with the right settings)."

Is there a way to do this manually for us users that have old databases? Some kind of export import manual procedure?

This isn't blocking, but it would be nice to see if there's a way that we could do it when we go from betas -> final (ie: first time final releases) to ensure everyone there has a good experience. Also, if there *is* a manual way to do this, we should relnote and blog about it heartily.

talking to dr richard hipp about this, what we really want is a modified version of vacuum. vacuum basically creates a temporary db, attach it to the current connection, creates the tables (based on what's in the old db), and then selects from the old db and inserts into the new one. vacuum does exactly what we want, except that vacuum will use the "old" databases page size when creating the new one. from sqlite.c, see sqlite3RunVacuum() sqlite3BtreeSetPageSize(pTemp, sqlite3BtreeGetPageSize(pMain), sqlite3BtreeGetReserve(pMain)); the operands to vacuum are unused, from sqlite.c, sqlite3VdbeAddOp(v, OP_Vacuum, 0, 0); dr hipp thought it might be a good idea to allow the user to specify the page size, reserve page size, and autovacuum (a boolean, to indicate none or not, since if not none, you can change between incremental and full even after the db is created). he had an idea of using the signedness of the first operand to represent the autovacuum setting. note, none of this is in sqlite 3.4.1, so we might make a local modification and work to get it up stream.

about the vacuum rfe, see http://www.sqlite.org/cvstrac/tktview?tn=2756

note, we'd want to disable incremental vacuum, not enable it. updating summary. confirm this doesn't block us from shipping fx 3.

We're long past the point of needing to do this. Anyone who does have a db from that window in time has long since learned to live with it, or it's just not causing problems.

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv