> On May 10, 2017, at 10:49 AM, Simon Slavin wrote:
>
> On 10 May 2017, at 6:31pm, Ward WIllats wrote:
>
>> I guess with corruption, all bets are off
>
> I see your results from "pragma integrity_check". As you write, "all bets
> are off".
On 5/10/17, Ward WIllats wrote:
>
> The unusual parts of our setup are:
>
> 1. The DB in questions is on a volatile filesystem and ATTACHED to another,
> smaller one residing on a flash (JFFS) filesystem, and
> 2. We use the shady SQLITE_SHM_DIRECTORY compile switch to
> On May 10, 2017, at 2:20 PM, Simon Slavin wrote:
> I’m concerned that this sort of corruption is happening repeatedly. Whether
> or not there’s anything in howtocorrupt.html that rings any bells, you can
> rely on us to help figure out what’s wrong.
>
Thanks. That's
On 10 May 2017, at 9:26pm, Ward WIllats wrote:
> But, we didn't do this in this case because a "disk full" error is not the
> CORRUPT or NOTADB error we expected to see to trigger the panic. So I was
> surprised, but...
I suspect that your initial post is correct,
> On May 10, 2017, at 10:49 AM, Simon Slavin wrote:
>
> On 10 May 2017, at 6:31pm, Ward WIllats wrote:
>
>> I guess with corruption, all bets are off
>
> I see your results from "pragma integrity_check". As you write, "all bets
> are off".
On 10 May 2017, at 6:31pm, Ward WIllats wrote:
> I guess with corruption, all bets are off
I see your results from "pragma integrity_check". As you write, "all bets are
off".
If your database is corrupt, any operation on it might silently lead to more
corruption.
Hello.
We have a DB with a corrupted index (see below). The database has a max_pages
limit that works out to a 10 MB database size (we're embedded).
We can insert into the table the index is on OK.
When we do a SELECT out of the table that uses the index, we get a "disk or
database full"
7 matches
Mail list logo