Re: [sqlite] page checksums (was Re: Bad db feature request)

2016-06-29 Thread Scott Robison
On Jun 29, 2016 10:14 PM, "Roger Binns"  wrote:
>
> On 29/06/16 19:13, Scott Robison wrote:
> > Given the nature of VFS, it is trivial* for anyone to create a module to
> > provide this very functionality. So you can write it yourself!
> >
> > *Not really trivial, but probably not horribly difficult either.
>
> VFS is one way you can't reasonably do it.  The VFS is handed full size
> pages, so the checksums would have to be stored somewhere other than the
> page.  That leads to a *very* complex implementation.

I'm not suggesting it is an ideal solution. Just that at least one solution
exists. Given the flexibility demonstrated in VFS sample implementations,
it is one possibility.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] page checksums (was Re: Bad db feature request)

2016-06-29 Thread Roger Binns
On 29/06/16 19:13, Scott Robison wrote:
> Given the nature of VFS, it is trivial* for anyone to create a module to
> provide this very functionality. So you can write it yourself!
> 
> *Not really trivial, but probably not horribly difficult either.

VFS is one way you can't reasonably do it.  The VFS is handed full size
pages, so the checksums would have to be stored somewhere other than the
page.  That leads to a *very* complex implementation.

The encryption extension does something like defining SQLITE_HAS_CODEC
and then gets to use a small amount of each page to store information
about the encryption of that page.  Checksums would fit very well into a
similar implementation.

Roger




signature.asc
Description: OpenPGP digital signature
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] page checksums (was Re: Bad db feature request)

2016-06-29 Thread Scott Robison
On Jun 29, 2016 5:08 PM, "Darren Duncan"  wrote:
> I notice that the ticket rejection didn't include any rationale or
explanation, or I didn't find any when I looked.  What was the rationale
for rejecting that ticket?
>
> I believe that SQLite having page checksums would be a good idea whose
time has come.  Even Postgres on whom SQLite takes a lot of influence has
had that feature for the last 2.5 years.
>
> This should be doable as an optional-per-file feature, like some other
features like foreign keys are optional.  If the feature is used, that is a
file format break so older SQLite versions won't attempt to modify a file,
and if a file doesn't use the feature then older SQLite versions will still
work with it.
>
> -- Darren Duncan

Given the nature of VFS, it is trivial* for anyone to create a module to
provide this very functionality. So you can write it yourself!

*Not really trivial, but probably not horribly difficult either.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


[sqlite] page checksums (was Re: Bad db feature request)

2016-06-29 Thread Darren Duncan

On 2016-06-29 8:12 AM, Roger Binns wrote:

On 29/06/16 07:51, Dominique Devienne wrote:

I wish for the day SQLite has page checksums to detect any such random
corruption.


Agreed.  The SQLite team rejected doing so:

   http://www.sqlite.org/src/tktview/72b01a982a84f64d4284


Yes, I know, it's a format change, and will likely slow things down a
little, but it's worth it IMHO.


Note that it isn't as big a change as you think, and could be done
today.  SQLite already allows a portion of each page to be used for
other purposes, with the big user being encryption.


I notice that the ticket rejection didn't include any rationale or explanation, 
or I didn't find any when I looked.  What was the rationale for rejecting that 
ticket?


I believe that SQLite having page checksums would be a good idea whose time has 
come.  Even Postgres on whom SQLite takes a lot of influence has had that 
feature for the last 2.5 years.


This should be doable as an optional-per-file feature, like some other features 
like foreign keys are optional.  If the feature is used, that is a file format 
break so older SQLite versions won't attempt to modify a file, and if a file 
doesn't use the feature then older SQLite versions will still work with it.


-- Darren Duncan

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users