On Sat, Aug 17, 2013 at 11:47 AM, Keith Medcalf wrote:
> > On 16.08.2013 18:03, Gary Weaver wrote:
> > You're right concurrency is not outlandish but from the viewpoint of
> > sqlite it was therefore this answer and the link.
>
> Hold on here.
>
> What do you mean "it works
> On 16.08.2013 18:03, Gary Weaver wrote:
> > Thanks to you and Richard for the links and info. Concurrency is not
> outlandish to expect, especially when it works in OS X and just not in
> the Ubuntu vm in Travis, but I now understand that these are expected
> problems.
> >
Yuriy,
Thanks for following up. Henrik of TravisCI had said that "We do not use
network filesystems by default. We do use ramfs for some databases, but I
don't think SQLite would use ramfs by default unless you put the database
in an odd location. I'm also fairly sure we don't disable locks in
On 16.08.2013 18:03, Gary Weaver wrote:
Thanks to you and Richard for the links and info. Concurrency is not outlandish
to expect, especially when it works in OS X and just not in the Ubuntu vm in
Travis, but I now understand that these are expected problems.
Gary Weaver wrote:
> On Aug 15, 2013, at 3:47 PM, ibrahim wrote:
>
>> On 15.08.2013 21:39, Gary Weaver wrote:
>>> SQLite varies between file is encrypted/not a DB errors and database disk
>>> image is malformed. It would seem consistent with SQLite not handling
>>>
On 16 Aug 2013, at 5:03pm, Gary Weaver wrote:
> Thanks to you and Richard for the links and info. Concurrency is not
> outlandish to expect, especially when it works in OS X and just not in the
> Ubuntu vm in Travis, but I now understand that these are expected
On Aug 15, 2013, at 3:47 PM, ibrahim wrote:
> On 15.08.2013 21:39, Gary Weaver wrote:
>> SQLite varies between file is encrypted/not a DB errors and database disk
>> image is malformed. It would seem consistent with SQLite not handling
>> concurrent processing in
On 15.08.2013 21:39, Gary Weaver wrote:
SQLite varies between file is encrypted/not a DB errors and database disk image
is malformed. It would seem consistent with SQLite not handling concurrent
processing in this particular environment or with the version of SQLite since
3.7.7 is fine in OS
On Fri, Aug 16, 2013 at 6:58 AM, Gary Weaver wrote:
>
> I'm going to stop on this for now, because it sounds like SQLite was never
> intended to support concurrent writes to a file DB from what you said, so
> there is no use trying to debug an use case that isn't
On Thu, Aug 15, 2013 at 4:20 PM, Richard Hipp wrote:
> On Thu, Aug 15, 2013 at 3:39 PM, Gary Weaver
> wrote:
>
> >
> > Is there anything that stands out as something that would keep 30
> > processes from being able to concurrently insert into the same
On Thu, Aug 15, 2013 at 3:39 PM, Gary Weaver wrote:
>
> Is there anything that stands out as something that would keep 30
> processes from being able to concurrently insert into the same tables?
>
Yes. SQLite does not (and has never) supported that. Multiple processes
On Aug 15, 2013, at 3:20 PM, Richard Hipp wrote:
> On Thu, Aug 15, 2013 at 3:10 PM, Gary Weaver wrote:
>
>> SQLite DB (file) corruption in travisci vm with 3.7.9 (latest they had
>> available). Link to logs showing errors, code to reproduce here:
>>
On Thu, Aug 15, 2013 at 3:10 PM, Gary Weaver wrote:
> SQLite DB (file) corruption in travisci vm with 3.7.9 (latest they had
> available). Link to logs showing errors, code to reproduce here:
> https://github.com/travis-ci/travis-ci/issues/1334
>
> Is there something in
SQLite DB (file) corruption in travisci vm with 3.7.9 (latest they had
available). Link to logs showing errors, code to reproduce here:
https://github.com/travis-ci/travis-ci/issues/1334
Is there something in config, etc. that would help?
___
14 matches
Mail list logo