So I tracked down the commit which introduced the "truncated page is fine"
behaviour:
$ fossil info 647e3b156e
uuid: 647e3b156e32e37debd60b0079fc5a52bdc9b8c8 2009-03-28 06:59:41
UTC
parent: 1c6521e53b846eec2e046b1e9c04c60658b8e0e8 2009-03-27 15:26:03
UTC
child:c9fa329f54736de
On 13 January 2017 at 22:59, David Raymond wrote:
> My view is that the general thinking of the program here is simply: "just
> don't make things worse." It can't help what pragmas (ie
> ignore_check_constraints, writable_schema etc) others may have turned on
> for their connections, or what sort
On Fri, 13 Jan 2017 11:17:11 +0800
Rowan Worth wrote:
> I wonder if this is something sqlite could catch in normal operation
> and return SQLITE_CORRUPT? Or are there reasons/history which would
> render this conclusion inaccurate?
Not without cost.
In general, it's difficult for any program
My view is that the general thinking of the program here is simply: "just don't
make things worse." It can't help what pragmas (ie ignore_check_constraints,
writable_schema etc) others may have turned on for their connections, or what
sort of junk was there when it arrived. In its head it's goin
4 matches
Mail list logo