[sqlite] Unnecessary calls to sqlite3AddColumn during ALTER TABLE ADD COLUMN

Hi all, I've recently been looking into the implementation of sqlite3. I've added some prints to instrument various parts of the implementation in order to get a better picture of how things work. I've noticed some strange behaviour when performing ALTER TABLE ADD COLUMN queries. It appears that

Re: [sqlite] Unnecessary calls to sqlite3AddColumn during ALTER TABLE ADD COLUMN

On 6/8/17, s1341 wrote: > Hi all, > > I've recently been looking into the implementation of sqlite3. I've added > some prints to instrument various parts of the implementation in order to > get a better picture of how things work. > > I've noticed some strange behaviour when

Re: [sqlite] Version 3.19.3 containing an important bug fix

On 6/8/17, Bob Friesenhahn wrote: > On Thu, 8 Jun 2017, D. Richard Hipp wrote: > >> A bug in the auto_vacuum logic for SQLite versions 3.16.0 through >> 3.19.2 can (rarely) lead to database corruption. SQLite version >> 3.19.3 has just been released to fix this bug.

Re: [sqlite] Questions about SQLite Encryption Extension (SEE)

On 6/8/17, Karl Sanders wrote: > I would like to know if an encrypted database allows hot backups and > page sizes different from the default one. Yes and Yes. > > Is encryption applied to everything that gets written to disk? > Including transient indices and

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

SQLite is primarily an _embedded_ database library. In that use case, comments on the schema properly belong in the program that creates the database, next to the sqlite3_exec("CREATE TABLE…”) calls. I realize that when SQLite is being used as a command-line DBM tool, having comments in the

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On Thu, Jun 8, 2017 at 12:15 PM, Jens Alfke wrote: > SQLite is primarily an _embedded_ database library. In that use case, > comments on the schema properly belong in the program that creates the > database, next to the sqlite3_exec("CREATE TABLE…”) calls. > > I realize that

Re: [sqlite] Questions about SQLite Encryption Extension (SEE)

Just musing: is an encrypted disk not more reliable? You have to store the key somewhere… On Thu, Jun 8, 2017, 7:07 PM Richard Hipp wrote: > On 6/8/17, Karl Sanders wrote: > > I would like to know if an encrypted database allows hot backups and > >

Re: [sqlite] Verison 3.19.2 no longer opens my database

What Richard asks, and, can you open the database from the command line using sqlite3.exe? On Thu, Jun 8, 2017 at 1:20 PM, Richard Hipp wrote: > Can you get us a backtrace? > > On 6/8/17, Martin Lowry wrote: > > Hi All, > > > > I've been using SQLite3 for

Re: [sqlite] Questions about SQLite Encryption Extension (SEE)

On 6/8/17, Wout Mertens wrote: > Just musing: is an encrypted disk not more reliable? You have to store the > key somewhere… Maybe. I guess it depends on your threat model. Encrypting the whole disk is a system setting,. Anybody who has access to the system can see

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

"CREATE TABLE meta_comments" Simon, isn't your approach the most logical solution rather than incorporating a comment column into the master? Once incorporated, wouldn't you be opening yourself up to a litany of "Not the way we work", "We need feature x to be useful", "What if we want a null

[sqlite] Version 3.19.3 containing an important bug fix

A bug in the auto_vacuum logic for SQLite versions 3.16.0 through 3.19.2 can (rarely) lead to database corruption. SQLite version 3.19.3 has just been released to fix this bug. https://sqlite.org/ https://sqlite.org/download.html See https://www.sqlite.org/src/info/fda22108 for more

[sqlite] Questions about SQLite Encryption Extension (SEE)

I would like to know if an encrypted database allows hot backups and page sizes different from the default one. Is encryption applied to everything that gets written to disk? Including transient indices and materializations of views and subqueries? Regards, Karl

Re: [sqlite] Version 3.19.3 containing an important bug fix

On Thu, 8 Jun 2017, Richard Hipp wrote: We are using 3.17.0 (under Linux on 32-bit MIPS) and have been getting a database is corrupted report (as reported earlier to this list), with this call backtrace: The line numbers in the backtrace below do not align with version 3.17.0. Have you made

Re: [sqlite] Version 3.19.3 containing an important bug fix

On Thu, 8 Jun 2017, D. Richard Hipp wrote: A bug in the auto_vacuum logic for SQLite versions 3.16.0 through 3.19.2 can (rarely) lead to database corruption. SQLite version 3.19.3 has just been released to fix this bug. Does 'pragma integrity_check' reliably detect this database

[sqlite] Verison 3.19.2 no longer opens my database

Hi All, I've been using SQLite3 for several years but recently installed version 3.19.2 and now my application fails to open the database. I was using 3.11.1 and had no problems. Now no matter how I try to open the DB my app always fails with a SIGSEGV in sqlite3_result_subtype (#14324). The

Re: [sqlite] Verison 3.19.2 no longer opens my database

Can you get us a backtrace? On 6/8/17, Martin Lowry wrote: > Hi All, > > I've been using SQLite3 for several years but recently installed version > 3.19.2 and now my application fails to open the database. I was using > 3.11.1 and had no problems. Now no matter how I try to

Re: [sqlite] Version 3.19.3 containing an important bug fix

On 6/8/17, Bob Friesenhahn wrote: > On Thu, 8 Jun 2017, Richard Hipp wrote: >>> >>> We are using 3.17.0 (under Linux on 32-bit MIPS) and have been getting >>> a database is corrupted report (as reported earlier to this list), >>> with this call backtrace: >> >> The

Re: [sqlite] Version 3.19.3 containing an important bug fix

On 6/8/17, Tony Papadimitriou wrote: > Does this also affect FOSSIL, or is auto vacuum never used there? > Fossil does not use auto_vacuum by default. So it probably does not affect it. However, a sufficiently motivated Fossil administrator could use the "fossil sql" command to

Re: [sqlite] Version 3.19.3 containing an important bug fix

Does this also affect FOSSIL, or is auto vacuum never used there? -Original Message- From: D. Richard Hipp Sent: Thursday, June 08, 2017 6:57 PM To: sqlite-annou...@mailinglists.sqlite.org ; sqlite-users@mailinglists.sqlite.org Subject: [sqlite] Version 3.19.3 containing an important

Re: [sqlite] Questions about SQLite Encryption Extension (SEE)

Isn't it all just obfuscation? Any root user can read your key, if not from disk then from memory. Any normal user can't read your key, nor from disk, nor from memory; and they can't read your db file either. So if the adversary is someone with access to your disk image, disk encryption trumps db

Re: [sqlite] Questions about SQLite Encryption Extension (SEE)

On 8 Jun 2017, at 11:13pm, Wout Mertens wrote: > So if the adversary is someone with access to your disk image, disk > encryption trumps db encryption (unless the disk encryption is vulnerable > to known-plaintext attacks, but I guess they probably apply to sqlite too).